-
Notifications
You must be signed in to change notification settings - Fork 772
{numlib}[GCC/7.3.0-2.30,dummy/dummy,goblf/2018b,gompi/2018b] goblf v2018b, HPL v2.2, LAPACK v3.8.0, ... #6615
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
{numlib}[GCC/7.3.0-2.30,dummy/dummy,goblf/2018b,gompi/2018b] goblf v2018b, HPL v2.2, LAPACK v3.8.0, ... #6615
Conversation
…8.0-GCC-7.3.0-2.30.eb, ScaLAPACK-2.0.2-gompi-2018b-BLIS-0.3.2.eb
|
On Sandy Bridge single node (theoretical peak: ~333 Gflops) HPL test using 16 cores with ~50% of memory (32G out of 64G) used (mpirun --bind-to core -n 16 xhpl with OMP_NUM_THREADS=1) goblf (BLIS) foss (OpenBLAS) gomkl (MKL) will test on SkyLake (avx512) later. |
|
@akesandgren dgren mentioned I should vary NB, so I will post some more results for Sandy Bridge once those are finished. and for SkyLake (chip: 8160 Platinum with 48 cores, peak: 2150 Gflops at 1.4 GHz avx512): so here as expected blis outperforms openblas (since openblas does not support avx512 yet for double precision -- it is approaching its AVX2 peak of 1382 Gflops though at 1.8 GHz avx2). I'll do another run with intel's own mplinpack that is part of MKL for comparison. |
|
Closing and reopening to trigger travis. |
|
Hmm that failure looks overly strict unless I am missing something. @boegel ? |
|
@bartoldeman We tried to keep things synced across different toolchains from the same generation, but of course that doesn't make sense for ScaLAPACK, so we'll need to add an exception to |
|
@boegel thanks for confirming, I'll work on the test |
|
@bartoldeman Based on the benchmarking you did, do you feel we should consider switching away from OpenBLAS in favor of BLIS in future generations of In any case, we should open an issue on that and collect some info there, since there's obviously more to it than just performance (e.g. can BLIS be considered stable/complete yet, etc.)? |
|
I'm not sure. Certainly BLIS outperforms OpenBLAS on avx512, but on other platforms it's not the case. BLIS certainly looks complete but I am not sure how fast it is for other functions (non-DGEMM). Also it looks like by the time foss 2019a is out OpenBLAS is fast again on avx512 given recent contributions by @fenrus75 (see https://github.com/xianyi/OpenBLAS/pulls?utf8=%E2%9C%93&q=author%3Afenrus75 ) |
|
@bartoldeman Well, ok, but it would still be useful to have a dedicated issue on that, to have a central place to track pros & cons to take into account. |
|
@boegel agreed about the issue. |
|
Rekicking Travis due to changes in EasyBuild testing |
|
Travis kicked |
|
ah the failing test reminds me the old issue is still there: |
|
@bartoldeman Does it make sense to pursue this, now that we have |
|
It's just the underlying testsuite issue that's blocking it, would be good to sort that out. |
…30734_new_pr_goblf2018b
For ScaLAPACK in BLIS-based vs OpenBLAS-based toolchains, we allow a dependency on a particular version, as long as that's indicated by the versionsuffix
as used in goblf toolchain. This is the proper fix.
|
@boegelbot please test @ generoso |
|
@bartoldeman: Request for testing this PR well received on generoso PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 743330521 processed Message to humans: this is just bookkeeping information for me, |
boegel
left a comment
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.
lgtm
|
Test report by @boegelbot |
|
Test report by @boegel |
|
Test report by @boegel |
|
Test report by @boegel |
|
Test report by @boegel |
|
Going in, thanks @bartoldeman! |
(created using
eb --new-pr)