dgesdd performance penalty

[jschueller]

hi, I have found another potential performance issue though not as severe as #5402:

I'm doing a full svd decomposition with dgesdd with an increasing number of rows with a moderate matrix size (n=1 to 300, m=1000),
for convenience I wrote the test-case in Python but it follows closely what I observe from C++ with the direct call to dgesdd from the C/Fortran interface.

import numpy as np

rng = np.random.default_rng()

m = 1000
for n in range(1, 300):
    print(n, flush=True)
    a = rng.normal(size=(n, m))
    U, S, Vh = np.linalg.svd(a, full_matrices=True)

On my machine (intel xeon) it takes ~1m with the default number of threads (40), but only ~35s with OMP_NUM_THREADS=1

This is Fedora rawhide again with openblas version 0.3.29.

[martin-frbg]

Hmm. There's no equally obvious culprit on the call graph of DGESDD, must be either an old threshold that is no longer appropiate for current hardware (DSCAL may actually switch to multithreading too late, #5327/#5328) , or simply the current all-or-nothing approach (that GEMM and GEMV are already deviating from on recent arm64 hardware).
Will need to run perf on your example when I have time.

[martin-frbg]

The bottleneck turned out to be the call to DGER - I have moved the threshold for full multithreading to larger problem sizes, and inserted a 3-thread stage at the old threshold.

[jschueller]

thanks