-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenBLAS becomes single-threaded #1820
Comments
Weird. Does matrix size change by the time you notice the number of active threads going down ? Many BLAS drivers now fall back to using a single thread when the overhead of multithreading is expected to exceed the gain from parallelizing, but this is always local to the individual function. Also most LAPACK functions are copied unmodified from the netlib reference implementation, so the LAPACK itself is not multithreaded. |
In fact it happens during treatment of a single matrix. I noticed the same behavior with 0.2.20 hence I upgraded. The inference of single-thread behavior comes from looking at output of "top" added: |
So what are the dimensions of that particular matrix, and which function is it that appears to execute single-threaded ? (Could be a missed or misguided optimization in OpenBLAS, but if you already saw this with 0.2.20 at least it is not a recent regression.) I presume your "standard openMP code" will be using some other implementation of BLAS (like MKL or ATLAS), or is it avoiding BLAS completely ? |
I checked matrices of sizes 1800 and 3800. The problem appears with lapack routine ZHEEV: the standard openMP code I referred to uses no BLAS at all, just to be sure. |
For that one needs to look at what ZHEEV in netlib LAPACK does - at first glance it uses DSTERF if only eigenvalues are requested, and ZSTEQR when both eigenvalues and eigenvectors. I have not yet traced the BLAS calls (if any) in the two call trees. (Does your standard code avoid LAPACK calls as well, or which LAPACK does it link to when not using OpenBLAS ?) |
my "standard" code uses no LAPACK stuff at all. Just filling matrices, a dumb case as a test. |
Calling LAPACK DSTEQR leads to the same problem when I want all eigenvectors of a real matrix. |
I now remember that we have #1560 as a related issue, and from what I managed to find out there it was the call to ZLASR in the eigenvectors case that was the bottleneck. |
... which more or less comes from unnecessary parallelism for small samples given to blas functions .... |
so perf record without any settings
|
now with
|
zhemv has no ththreading threshold |
Execution times would complete the picture, but I doubt they will be markedly different (note that the first message has "goes down to one thread with miserable performance"). Once the program enters the non-parallelized netlib ZLASR all the work is done by a single core, no BLAS involved. |
I am into thinking zlasr work is same for both cases, just that it takes 30 or 80% depending on zhemv ?waste |
similar behavior for DSTEQR first without any settings:
|
now DSTEQR with 80.43% su2lapack.exe libopenblas_nehalemp-r0.3.3.so [.] dlasr_ |
Timings DSTEQR: |
@martin-frbg I will |
@martin-frbg philosophically low threshold for input is page size, for output cache line , assuming all chunks are aligned, upper bound L3cache (i.e we do not add extra thread to split threshold more) |
@tjoli temp fix while I get better moderation of threading is to disable it altogether in interface/zhemv.c:
becomes
|
Using benchmarks included |
@martin-frbg I would guess at "guarantee each core at least half of L3 chunk of data?" |
If it is L3 - interestingly nothing uses the L3_SIZE datum returned by getarch. Probably best to bind the calculation to GEMM_MULTITHREAD_THRESHOLD for consistency. Maybe even just naively copy the initial threshold from (say) zgemv.c and see where that leads you. (BTW I wonder what causes that extreme jitter in the 2-thread curves, c2 in particular) |
Jitter made me wonder too. |
The method and assumptions regarding underlying mechanism were quite simple.
At least 1vs2vs3 cores is interesting to know if it is steps to take gradually or one, then all is viable. |
@tjoli - can you test? It is very rough and simple change. |
with
the behavior is similar as seen from "top": goes single-threaded after few seconds. same parameters as in post 4 days ago, the results were 30.43% lapack.exe libopenblas_nehalemp-r0.3.3.so [.] zlasr_ |
zlasr_ is single-threaded Yes, the performance target is not to stress-test CPU cooling, but to give result faster. Can you get 2 outputs with OPENBLAS_NUM_THREADS=2 and =3 - i have some doubts about assumptions I made with one single threshold measuring just once, thank you. |
so with openblas_num_threads=2 |
and with openblas_num_threads=3
|
@martin-frbg it does not look as tragic as old one? Could it survive few releases in this form? |
@tjoli _lasr group is a fancy memcpy, with like 3 FLOPS per memory read+write(each dozen flops worth), it will not gain much from parallelism. Maybe it can gain from some inlining of loops so that compiler vectorizes & prefetches better, but thats again just 5% as memory accesses need to be. |
@tjoli any changes to the running times with the patch ? Keeping zhemv from causing unnecessary overhead should make timings more similar between single- and multithreaded runs, but any more fundamental improvements would require a different algorithm than xSTEQR (same as in #1560, where I linked to a research paper from the developers of libflame. Not sure if/how that work maps to the current version of their library - which sports its own, non-LAPACK compatible API) |
@tjoli regarding hardware setup for performance: If it is westmere then x86_energy_perf_policy (from cpupower or cpufreq package) may be used to set CPU to maximum power. Also usual advice on "set BIOS to defaults" and "read vendor guide specific to your OS" apply. And for electricity burned you probably can get modern i3 laptop that jumps circles around your server. |
Delay _hemv threading in attempt to address #1820
@martin-frbg I understand that a different algorithm is needed indeed. I am just too lazy and always jump onto LAPACK. @brada4 I use HT because I have better performance with some custom MPI code but the gain is of course is really spectacular - it exists when going from 6 to 8 threads and vanishes beyond. And right at home my i5 is way faster... |
There is no code improvement expected in short-term.
For your further experimentation: If clang+flang is at hand they may generate different if not better LAPACK code. Try to experiment with energy_perf_policy - it may allow 1st hyperthread to work at 100% of core while other sleeps (for ZLASR) while still permitting 50:50 split for your MPI code. x86_e_p_p not work with nehalem, but will work with westmere and better. Depending on your needs you may find other function giving result of proper accuracy faster: Also consider casting down to single percisions (loss of accuracy if that matters, but result comes in half time) |
If you qualify for free MKL it might be worth trying, while BLAS part is more or less on par, they have some algorithmic improvements in LAPACK side over reference LAPACK used by OpenBLAS. |
related ticket in Reference-LAPACK was Reference-LAPACK/lapack#710 (still need to get to implementing the suggested algorithm) |
Hi everybody,
I am using standard lapack routines to diagonalize moderately large matrices with openBLAS.
The box is a xeon with 6 cores and hyperthreading. At runtime execution starts with 12 threads
by default and after some reproducible time goes down to one thread with miserable performance
but execution is without errors. I have observed the same behavior with OMP_NUM_THREADS=2,4,6
and using also OPENBLAS_NUM_THREADS. I tried to set OMP_DYNAMIC=FALSE with no change of behavior. It is a locally compiled version of openBLAS 0.3.3 with gcc/gfortran 7.3.0
any hints would be appreciated !
The text was updated successfully, but these errors were encountered: