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
Update OpenBLAS build options #5091
Conversation
@@ -10,12 +10,12 @@ Source: https://github.com/xianyi/OpenBLAS/archive/v%{realversion}.tar.gz | |||
|
|||
# PRESCOTT is a generic x86-64 target https://github.com/xianyi/OpenBLAS/issues/685 | |||
%ifarch x86_64 | |||
make FC=gfortran BINARY=64 TARGET=PENRYN NUM_THREADS=256 DYNAMIC_ARCH=1 | |||
make FC=gfortran BINARY=64 TARGET=CORE2 NUM_THREADS=256 DYNAMIC_ARCH=0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does the NUM_THREADS
actually correspond to in reality at run time?
Was the speedup seen in tests of deepAK8 real or a simple parallelization on a quiet node?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@slava77 What affects the number of threads used at runtime is the OPENBLAS_NUM_THREADS
environment variable which is set to 1 in https://github.com/cms-sw/cmsdist/blob/IB/CMSSW_11_0_X/gcc700/OpenBLAS-toolfile.spec#L19. NUM_THREADS
is the maximum allowed number of threads and is used for resource allocation etc. I explicitly checked the CPU usage when running the tests and it was not going beyond 100%:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And gslblas
is known to be not a very high-performance BLAS routine, so the speed-up we saw after switching to OpenBLAS
should not be surprising at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for clarifications
@cmsbuild please test |
The tests are being triggered in jenkins. |
-1 Tested at: 2b925b4 You can see the results of the tests here: I found follow errors while testing this PR Failed tests: UnitTests
I found errors in the following unit tests: ---> test ExpressionEvaluatorUnitTest had ERRORS |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
It looks like the tests passed OK. The unit test failure seems unrelated. There is a difference in 136.788 step3 logs, which also appears to be unrelated:
We've seen something like this non-reproducible showing up in some other external tests. |
please test |
The tests are being triggered in jenkins. |
The timing report above does not seem consistent with the baseline IB result
although the conditions are not identically the same (baseline is multithreaded, the PR test is not) |
it looks like a different workflow now has a similar warning. In 136.85
still, unrelated to the openblas use case. |
We are not observing these excesses in the baseline tests as far as I can see in recent IBs, but is it clear that if the happens randomly they are difficult to track, In any case the only TimeOut failure we have recently had was almost systematic, understood and solved. @mrodozov do you have a way to check for instance the average time from recent IBs? This is one of the use cases where monitoring plots turn to be useful... |
Hi Fabio, sry for the delay but I had to check what could be used and what we have, https://es-cmssdt.cern.ch/kibana_rw/app/kibana#/discover?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now%2Fw,mode:quick,to:now%2Fw))&_a=(columns:!(package,release,step,workflow,TotalJobTime,MaxEventTime,MinEventTime,AvgEventTime),index:AWvhEvG8LPbZ6C4ywF-2,interval:auto,query:(match_all:()),sort:!('@timestamp',desc)) @gudrutis is pushing it to have things ready to be used on Grafana (has better plotting options than Kibana) |
+externals |
This pull request is fully signed and it will be integrated in one of the next IB/CMSSW_11_0_X/gcc700 IBs (tests are also fine). This pull request will be automatically merged. |
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
To address cms-sw/cmssw#27504.
DYNAMIC_ARCH=0
TARGET=CORE2
to be consistent with what's generally used in CMSSW