Andrey Bokhanko
2015-Apr-30 13:49 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
All, I'd like to resurrect the discussion on replacing libgomp with libiomp as the default OpenMP runtime library linked with -fopenmp. For reference, the previous discussion is accessible there: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 We are very close to getting *full* OpenMP 3.1 specification supported in clang (only one (!) clause is not implemented yet, and the patch is already sent for review today: http://reviews.llvm.org/D9370). This implementation generates Intel API library calls; thus, it can't be used with libgomp and it is simply logical to link a compatible runtime (libiomp) instead. Last time Chandler objected against doing this, and gave a good (and proper!) scolding. Let me quote his objections along with updates on current state of things: - This library is not being developed as an active part of the LLVM community, even if it is checked into SVN as part of the LLVM project and under its license. See r197914 where there is a code drop of many months worth of development with *no* change log, attribution, information, or other participation in any part of the community. Now it is actively developed by several members of the community. Changes are committed in small patches. See "openmp-commits" mailing list ( http://lists.cs.uiuc.edu/pipermail/openmp-commits/) for details. - There has been essentially *zero* discussion with the rest of the clang or llvm community about this library. There are separate mailing lists which have nearly no traffic since the code drop. Nowadays the traffic, while less than on llvm-dev mailing list (understandably so :-)) is far from being "zero". Discussions happen all the time. See the list archives for details ( http://lists.cs.uiuc.edu/pipermail/openmp-dev/). - There has been no effort to make this library even work properly with Clang as a host compiler. See the copious notes that only Clang 3.3 is supported, and that not full featured. This is fixed. - The build system is totally disjoint from LLVM's, in fact it is an entirely custom Perl build system that is unlike anything in use by the LLVM project. The build system is full re-written and now cmake-based. The last remaining step (integration into overall llvm build system) is about to be done by any day now ( http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500). - There are *zero tests* in the open source repository!!!! This is even called out in the original submission and on the primary website. We simply *cannot* ship and link against a runtime library which has no tests! UofHouston contributed a comprehensive test suite: http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/. - No part of this library has gone through an LLVM release process either, not even as a "new" or "beta" project. The whole library is a part of two last llvm releases: 3.5 and 3.6. Thus, I believe all of Chandler's concerns are resolved, and it is finally a good time time to switch to libiomp as default OpenMP library. Anyone who supports this? Anyone who disagrees? Chandler? Yours, Andrey Bokhanko =============Software Engineer Intel Compiler Team Intel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/f13af52a/attachment.html>
Hal Finkel
2015-Apr-30 14:06 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
----- Original Message -----> From: "Andrey Bokhanko" <andreybokhanko at gmail.com> > To: "cfe-dev" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Douglas Gregor" > <dgregor at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "C Bergström" <cbergstrom at pathscale.com>, "Michael Wong" > <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev at gmx.com> > Sent: Thursday, April 30, 2015 8:49:30 AM > Subject: libiomp, not libgomp as default library linked with -fopenmp > > > All, > > > I'd like to resurrect the discussion on replacing libgomp with > libiomp as the default OpenMP runtime library linked with -fopenmp. > > > For reference, the previous discussion is accessible there: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 > > > We are very close to getting *full* OpenMP 3.1 specification > supported in clang (only one (!) clause is not implemented yet, and > the patch is already sent for review today: > http://reviews.llvm.org/D9370 ). This implementation generates Intel > API library calls; thus, it can't be used with libgomp and it is > simply logical to link a compatible runtime (libiomp) instead.To be clear, this is now LLVM's OpenMP runtime (not just Intel's), and has been ported to several platforms in addition to x86 (PowerPC, ARM).> > > Last time Chandler objected against doing this, and gave a good (and > proper!) scolding. Let me quote his objections along with updates on > current state of things: > > > > > - This library is not being developed as an active part of the LLVM > community, even if it is checked into SVN as part of the LLVM > project and under its license. See r197914 where there is a code > drop of many months worth of development with *no* change log, > attribution, information, or other participation in any part of the > community. > > > > > Now it is actively developed by several members of the community. > Changes are committed in small patches. See "openmp-commits" mailing > list ( http://lists.cs.uiuc.edu/pipermail/openmp-commits/ ) for > details. > > > > > - There has been essentially *zero* discussion with the rest of the > clang or llvm community about this library. There are separate > mailing lists which have nearly no traffic since the code drop. > > > > > Nowadays the traffic, while less than on llvm-dev mailing list > (understandably so :-)) is far from being "zero". Discussions happen > all the time. See the list archives for details ( > http://lists.cs.uiuc.edu/pipermail/openmp-dev/ ). > > > > > - There has been no effort to make this library even work properly > with Clang as a host compiler. See the copious notes that only Clang > 3.3 is supported, and that not full featured. > > > > > This is fixed. > > > > > - The build system is totally disjoint from LLVM's, in fact it is an > entirely custom Perl build system that is unlike anything in use by > the LLVM project. > > > > > The build system is full re-written and now cmake-based. The last > remaining step (integration into overall llvm build system) is about > to be done by any day now ( > http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500 > ). > > > > > - There are *zero tests* in the open source repository!!!! This is > even called out in the original submission and on the primary > website. We simply *cannot* ship and link against a runtime library > which has no tests! > > > > > UofHouston contributed a comprehensive test suite: > http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/ . > > > > > - No part of this library has gone through an LLVM release process > either, not even as a "new" or "beta" project. > > > > > The whole library is a part of two last llvm releases: 3.5 and 3.6. > > > > > Thus, I believe all of Chandler's concerns are resolved, and it is > finally a good time time to switch to libiomp as default OpenMP > library. > > > > > Anyone who supports this? >I support this. Linking to libgomp will still be available by specifying -fopenmp=libgomp for those who need it. Our runtime supports a libgomp-compatible interface, so that's hopefully not necessary even for those with GCC-compiled OpenMP object files and libraries. We need to get the build system integration committed and the buildbots updated to compile it, and the test suite setup (the build system integration and test-suite setup have patches under review on the openmp list, so I suspect this will happen soon). Practically, since we don't have OpenMP in the test suite (yet), none of these are really inflexible prerequisites. In my opinion, as soon as the build system integration is done (so that people have an easy way to use LLVM's runtime), we should flip the defaults -- the other things will follow shortly. -Hal> > > > Anyone who disagrees? > > > > > Chandler? > > > Yours, > Andrey Bokhanko > =============> Software Engineer > Intel Compiler Team > Intel > >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Jack Howarth
2015-Apr-30 14:23 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
The current test suite status on x86_64-apple-darwin14, with the proposed patch from http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128219.html applied to current cfe trunk, is quite respectable.... Summary: S Number of tested Open MP constructs: 62 S Number of used tests: 123 S Number of failed tests: 16 S Number of successful tests: 107 S + from this were verified: 106 Normal tests: N Number of failed tests: 8 N + from this fail compilation: 1 N + from this timed out 0 N Number of successful tests: 54 N + from this were verified: 54 Orphaned tests: O Number of failed tests: 8 O + from this fail compilation: 0 O + from this timed out 0 O Number of successful tests: 53 O + from this were verified: 52 for 'make ctest' using "-fopenmp=libiomp5 -Xclang -fopenmp=libiomp5 -L/sw/opt/llvm-3.7.0/lib -lm -O3". Whereas for libgomp, the results are pitiful.... Summary: S Number of tested Open MP constructs: 62 S Number of used tests: 123 S Number of failed tests: 30 S Number of successful tests: 93 S + from this were verified: 12 Normal tests: N Number of failed tests: 15 N + from this fail compilation: 0 N + from this timed out 0 N Number of successful tests: 47 N + from this were verified: 6 Orphaned tests: O Number of failed tests: 15 O + from this fail compilation: 0 O + from this timed out 0 O Number of successful tests: 46 O + from this were verified: 6 when using "-fopenmp=libgomp -Xclang -fopenmp=libgomp -L/sw/lib/gcc5/lib -lm -O3 -Wl,-no_compact_unwind". So we can't get much more broken that the current behavior with libgomp. Jack On Thu, Apr 30, 2015 at 9:49 AM, Andrey Bokhanko <andreybokhanko at gmail.com> wrote:> All, > > I'd like to resurrect the discussion on replacing libgomp with libiomp as > the default OpenMP runtime library linked with -fopenmp. > > For reference, the previous discussion is accessible there: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 > > We are very close to getting *full* OpenMP 3.1 specification supported in > clang (only one (!) clause is not implemented yet, and the patch is already > sent for review today: http://reviews.llvm.org/D9370). This > implementation generates Intel API library calls; thus, it can't be used > with libgomp and it is simply logical to link a compatible runtime > (libiomp) instead. > > Last time Chandler objected against doing this, and gave a good (and > proper!) scolding. Let me quote his objections along with updates on > current state of things: > > - This library is not being developed as an active part of the LLVM > community, even if it is checked into SVN as part of the LLVM project and > under its license. See r197914 where there is a code drop of many months > worth of development with *no* change log, attribution, information, or > other participation in any part of the community. > > > Now it is actively developed by several members of the community. Changes > are committed in small patches. See "openmp-commits" mailing list ( > http://lists.cs.uiuc.edu/pipermail/openmp-commits/) for details. > > > - There has been essentially *zero* discussion with the rest of the clang > or llvm community about this library. There are separate mailing lists > which have nearly no traffic since the code drop. > > > Nowadays the traffic, while less than on llvm-dev mailing list > (understandably so :-)) is far from being "zero". Discussions happen all > the time. See the list archives for details ( > http://lists.cs.uiuc.edu/pipermail/openmp-dev/). > > > - There has been no effort to make this library even work properly with > Clang as a host compiler. See the copious notes that only Clang 3.3 is > supported, and that not full featured. > > > This is fixed. > > > - The build system is totally disjoint from LLVM's, in fact it is an > entirely custom Perl build system that is unlike anything in use by the > LLVM project. > > > The build system is full re-written and now cmake-based. The last > remaining step (integration into overall llvm build system) is about to be > done by any day now ( > http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500). > > > - There are *zero tests* in the open source repository!!!! This is even > called out in the original submission and on the primary website. We simply > *cannot* ship and link against a runtime library which has no tests! > > > UofHouston contributed a comprehensive test suite: > http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/. > > > - No part of this library has gone through an LLVM release process either, > not even as a "new" or "beta" project. > > > The whole library is a part of two last llvm releases: 3.5 and 3.6. > > > Thus, I believe all of Chandler's concerns are resolved, and it is finally > a good time time to switch to libiomp as default OpenMP library. > > > Anyone who supports this? > > > Anyone who disagrees? > > > Chandler? > > Yours, > Andrey Bokhanko > =============> Software Engineer > Intel Compiler Team > Intel > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/9c27d7da/attachment.html>
C Bergström
2015-Apr-30 14:25 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
On Thu, Apr 30, 2015 at 9:06 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- >> From: "Andrey Bokhanko" <andreybokhanko at gmail.com> >> To: "cfe-dev" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Douglas Gregor" >> <dgregor at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "C Bergström" <cbergstrom at pathscale.com>, "Michael Wong" >> <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev at gmx.com> >> Sent: Thursday, April 30, 2015 8:49:30 AM >> Subject: libiomp, not libgomp as default library linked with -fopenmp >> >> >> All, >> >> >> I'd like to resurrect the discussion on replacing libgomp with >> libiomp as the default OpenMP runtime library linked with -fopenmp. >> >> >> For reference, the previous discussion is accessible there: >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 >> >> >> We are very close to getting *full* OpenMP 3.1 specification >> supported in clang (only one (!) clause is not implemented yet, and >> the patch is already sent for review today: >> http://reviews.llvm.org/D9370 ). This implementation generates Intel >> API library calls; thus, it can't be used with libgomp and it is >> simply logical to link a compatible runtime (libiomp) instead. > > To be clear, this is now LLVM's OpenMP runtime (not just Intel's), and has been ported to several platforms in addition to x86 (PowerPC, ARM).It doesn't really feel that way. I proposed a cmake patch and the only person to review or comment was Intel. (This is coming from the person who ported it to ARM) To stay more agnostic I'd love to see a non-Intel owner. While Hal may not be the most active contributor - his reviews are invaluable and less biased. I don't know if Hal has the time or interest, but I'd nominate him for "owner". I see Tom wants to assign more owners, but I'd like to avoid this being an "Intel runtime owned and controlled by Intel"
John Leidel (jleidel)
2015-Apr-30 15:10 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
I definitely support Andrey’s proposal to move the default to libiomp. Outside of the known ports for x86, ARM and PowerPC, I’m aware of at least one other port in progress. More will likely follow. Per Hal’s notes, given the forthcoming commits of the CMake build system, flipping the default to libiomp may help spur/accelerate the progress of porting the runtime to new platforms (especially those that are already supported as LLVM backends). --John D. Leidel On Apr 30, 2015, at 9:06 AM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- >> From: "Andrey Bokhanko" <andreybokhanko at gmail.com> >> To: "cfe-dev" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Douglas Gregor" >> <dgregor at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "C Bergström" <cbergstrom at pathscale.com>, "Michael Wong" >> <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev at gmx.com> >> Sent: Thursday, April 30, 2015 8:49:30 AM >> Subject: libiomp, not libgomp as default library linked with -fopenmp >> >> >> All, >> >> >> I'd like to resurrect the discussion on replacing libgomp with >> libiomp as the default OpenMP runtime library linked with -fopenmp. >> >> >> For reference, the previous discussion is accessible there: >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 >> >> >> We are very close to getting *full* OpenMP 3.1 specification >> supported in clang (only one (!) clause is not implemented yet, and >> the patch is already sent for review today: >> http://reviews.llvm.org/D9370 ). This implementation generates Intel >> API library calls; thus, it can't be used with libgomp and it is >> simply logical to link a compatible runtime (libiomp) instead. > > To be clear, this is now LLVM's OpenMP runtime (not just Intel's), and has been ported to several platforms in addition to x86 (PowerPC, ARM). > >> >> >> Last time Chandler objected against doing this, and gave a good (and >> proper!) scolding. Let me quote his objections along with updates on >> current state of things: >> >> >> >> >> - This library is not being developed as an active part of the LLVM >> community, even if it is checked into SVN as part of the LLVM >> project and under its license. See r197914 where there is a code >> drop of many months worth of development with *no* change log, >> attribution, information, or other participation in any part of the >> community. >> >> >> >> >> Now it is actively developed by several members of the community. >> Changes are committed in small patches. See "openmp-commits" mailing >> list ( http://lists.cs.uiuc.edu/pipermail/openmp-commits/ ) for >> details. >> >> >> >> >> - There has been essentially *zero* discussion with the rest of the >> clang or llvm community about this library. There are separate >> mailing lists which have nearly no traffic since the code drop. >> >> >> >> >> Nowadays the traffic, while less than on llvm-dev mailing list >> (understandably so :-)) is far from being "zero". Discussions happen >> all the time. See the list archives for details ( >> http://lists.cs.uiuc.edu/pipermail/openmp-dev/ ). >> >> >> >> >> - There has been no effort to make this library even work properly >> with Clang as a host compiler. See the copious notes that only Clang >> 3.3 is supported, and that not full featured. >> >> >> >> >> This is fixed. >> >> >> >> >> - The build system is totally disjoint from LLVM's, in fact it is an >> entirely custom Perl build system that is unlike anything in use by >> the LLVM project. >> >> >> >> >> The build system is full re-written and now cmake-based. The last >> remaining step (integration into overall llvm build system) is about >> to be done by any day now ( >> http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500 >> ). >> >> >> >> >> - There are *zero tests* in the open source repository!!!! This is >> even called out in the original submission and on the primary >> website. We simply *cannot* ship and link against a runtime library >> which has no tests! >> >> >> >> >> UofHouston contributed a comprehensive test suite: >> http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/ . >> >> >> >> >> - No part of this library has gone through an LLVM release process >> either, not even as a "new" or "beta" project. >> >> >> >> >> The whole library is a part of two last llvm releases: 3.5 and 3.6. >> >> >> >> >> Thus, I believe all of Chandler's concerns are resolved, and it is >> finally a good time time to switch to libiomp as default OpenMP >> library. >> >> >> >> >> Anyone who supports this? >> > > I support this. Linking to libgomp will still be available by specifying -fopenmp=libgomp for those who need it. Our runtime supports a libgomp-compatible interface, so that's hopefully not necessary even for those with GCC-compiled OpenMP object files and libraries. > > We need to get the build system integration committed and the buildbots updated to compile it, and the test suite setup (the build system integration and test-suite setup have patches under review on the openmp list, so I suspect this will happen soon). Practically, since we don't have OpenMP in the test suite (yet), none of these are really inflexible prerequisites. In my opinion, as soon as the build system integration is done (so that people have an easy way to use LLVM's runtime), we should flip the defaults -- the other things will follow shortly. > > -Hal > >> >> >> >> Anyone who disagrees? >> >> >> >> >> Chandler? >> >> >> Yours, >> Andrey Bokhanko >> =============>> Software Engineer >> Intel Compiler Team >> Intel >> >> > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Jack Howarth
2015-Apr-30 15:41 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
On Thu, Apr 30, 2015 at 10:23 AM, Jack Howarth < howarth.mailing.lists at gmail.com> wrote:> The current test suite status on x86_64-apple-darwin14, with the > proposed patch from > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128219.html > applied to current cfe trunk, is quite respectable.... > > Summary: > S Number of tested Open MP constructs: 62 > S Number of used tests: 123 > S Number of failed tests: 16 > S Number of successful tests: 107 > S + from this were verified: 106 > > Normal tests: > N Number of failed tests: 8 > N + from this fail compilation: 1 > N + from this timed out 0 > N Number of successful tests: 54 > N + from this were verified: 54 > > Orphaned tests: > O Number of failed tests: 8 > O + from this fail compilation: 0 > O + from this timed out 0 > O Number of successful tests: 53 > O + from this were verified: 52 > > for 'make ctest' using "-fopenmp=libiomp5 -Xclang -fopenmp=libiomp5 > -L/sw/opt/llvm-3.7.0/lib -lm -O3". Whereas for libgomp, the results are > pitiful.... > > Summary: > S Number of tested Open MP constructs: 62 > S Number of used tests: 123 > S Number of failed tests: 30 > S Number of successful tests: 93 > S + from this were verified: 12 > > Normal tests: > N Number of failed tests: 15 > N + from this fail compilation: 0 > N + from this timed out 0 > N Number of successful tests: 47 > N + from this were verified: 6 > > Orphaned tests: > O Number of failed tests: 15 > O + from this fail compilation: 0 > O + from this timed out 0 > O Number of successful tests: 46 > O + from this were verified: 6 > >For additional context, the OpenMP3.1_Validation results for libgomp using the FSF gcc 5.1.0 compiler on x86_64-apple-darwin14 are... Summary: S Number of tested Open MP constructs: 62 S Number of used tests: 123 S Number of failed tests: 7 S Number of successful tests: 116 S + from this were verified: 95 Normal tests: N Number of failed tests: 3 N + from this fail compilation: 0 N + from this timed out 0 N Number of successful tests: 59 N + from this were verified: 48 Orphaned tests: O Number of failed tests: 4 O + from this fail compilation: 0 O + from this timed out 0 O Number of successful tests: 57 O + from this were verified: 47 So the current results for libiomp5 are very close to matching those for the FSF gcc compiler with libgomp in terms of the number of passed tests while libiomp5 already exceeds libgomp for the number of verified tests. when using "-fopenmp=libgomp -Xclang -fopenmp=libgomp -L/sw/lib/gcc5/lib> -lm -O3 -Wl,-no_compact_unwind". So we can't get much more broken that the > current behavior with libgomp. > Jack > > On Thu, Apr 30, 2015 at 9:49 AM, Andrey Bokhanko <andreybokhanko at gmail.com > > wrote: > >> All, >> >> I'd like to resurrect the discussion on replacing libgomp with libiomp as >> the default OpenMP runtime library linked with -fopenmp. >> >> For reference, the previous discussion is accessible there: >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 >> >> We are very close to getting *full* OpenMP 3.1 specification supported in >> clang (only one (!) clause is not implemented yet, and the patch is already >> sent for review today: http://reviews.llvm.org/D9370). This >> implementation generates Intel API library calls; thus, it can't be used >> with libgomp and it is simply logical to link a compatible runtime >> (libiomp) instead. >> >> Last time Chandler objected against doing this, and gave a good (and >> proper!) scolding. Let me quote his objections along with updates on >> current state of things: >> >> - This library is not being developed as an active part of the LLVM >> community, even if it is checked into SVN as part of the LLVM project and >> under its license. See r197914 where there is a code drop of many months >> worth of development with *no* change log, attribution, information, or >> other participation in any part of the community. >> >> >> Now it is actively developed by several members of the community. Changes >> are committed in small patches. See "openmp-commits" mailing list ( >> http://lists.cs.uiuc.edu/pipermail/openmp-commits/) for details. >> >> >> - There has been essentially *zero* discussion with the rest of the clang >> or llvm community about this library. There are separate mailing lists >> which have nearly no traffic since the code drop. >> >> >> Nowadays the traffic, while less than on llvm-dev mailing list >> (understandably so :-)) is far from being "zero". Discussions happen all >> the time. See the list archives for details ( >> http://lists.cs.uiuc.edu/pipermail/openmp-dev/). >> >> >> - There has been no effort to make this library even work properly with >> Clang as a host compiler. See the copious notes that only Clang 3.3 is >> supported, and that not full featured. >> >> >> This is fixed. >> >> >> - The build system is totally disjoint from LLVM's, in fact it is an >> entirely custom Perl build system that is unlike anything in use by the >> LLVM project. >> >> >> The build system is full re-written and now cmake-based. The last >> remaining step (integration into overall llvm build system) is about to be >> done by any day now ( >> http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500 >> ). >> >> >> - There are *zero tests* in the open source repository!!!! This is even >> called out in the original submission and on the primary website. We simply >> *cannot* ship and link against a runtime library which has no tests! >> >> >> UofHouston contributed a comprehensive test suite: >> http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/. >> >> >> - No part of this library has gone through an LLVM release process >> either, not even as a "new" or "beta" project. >> >> >> The whole library is a part of two last llvm releases: 3.5 and 3.6. >> >> >> Thus, I believe all of Chandler's concerns are resolved, and it is >> finally a good time time to switch to libiomp as default OpenMP library. >> >> >> Anyone who supports this? >> >> >> Anyone who disagrees? >> >> >> Chandler? >> >> Yours, >> Andrey Bokhanko >> =============>> Software Engineer >> Intel Compiler Team >> Intel >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/6043d4ff/attachment.html>
Ed Maste
2015-Apr-30 15:59 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
On 30 April 2015 at 10:06, Hal Finkel <hfinkel at anl.gov> wrote:>> >> I'd like to resurrect the discussion on replacing libgomp with >> libiomp as the default OpenMP runtime library linked with -fopenmp. >> >> >> For reference, the previous discussion is accessible there: >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 >> >> >> We are very close to getting *full* OpenMP 3.1 specification >> supported in clang (only one (!) clause is not implemented yet, and >> the patch is already sent for review today: >> http://reviews.llvm.org/D9370 ). This implementation generates Intel >> API library calls; thus, it can't be used with libgomp and it is >> simply logical to link a compatible runtime (libiomp) instead. > > To be clear, this is now LLVM's OpenMP runtime (not just Intel's), and has been ported to several platforms in addition to x86 (PowerPC, ARM).It looks like openmp/runtime/README.txt could use an update to clarify this status. The title is "README for the Intel(R) OpenMP* Runtime Library" and there's a of supported Intel architectures -- this gives a somewhat different impression than what's described in this thread. That said, I would also be happy to see the default switched to libiomp.
Chandler Carruth
2015-Apr-30 21:51 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <andreybokhanko at gmail.com> wrote:> All, > > I'd like to resurrect the discussion on replacing libgomp with libiomp as > the default OpenMP runtime library linked with -fopenmp. >Just for the record, I'm really excited to see this. =]> We are very close to getting *full* OpenMP 3.1 specification supported in > clang (only one (!) clause is not implemented yet, and the patch is already > sent for review today: http://reviews.llvm.org/D9370). This > implementation generates Intel API library calls; thus, it can't be used > with libgomp and it is simply logical to link a compatible runtime > (libiomp) instead. >Is there no way to support libgomp here as well? I don't say this to hold up changing the defaults in any way, just curious. =] Also, for the record, I'm really excited to see the progress here as well.> Chandler? >Hi! ;] I totally agree, I think things are way better now. I generally support the direction. I think there are a few things I'd suggest we do as part of the process, but I think these are really small and just about "how" we switch. 1) I completely agree with the comments some others have made about us needing to make it clear that this isn't some Intel-only thing, its the LLVM OpenMP runtime. Some suggestions that I think would make sense to help here: - I agree with finding some non-Intel folks to add as explicit code owners. I don't know who has been sufficiently involved, but if Hal makes sense, awesome. - Clearly updating the readme and such would be appropriate. - I suspect we should change the name of the installed library. 'libiomp' is pretty clearly the Intel library. We could continue in the grand tradition of LLVM naming conventions and use 'libllomp'? Of course, we should install symlinks under the name 'libiomp' if needed for existing users to not be broken. - Any other changes? 2) I think we need to update the instructions for checking out LLVM and all the tools to include checking out the openmp project. I'm planning to try it out in a bit. 3) It would be nice to get at least one boring benchmark into the test-suite that uses OpenMP just so there's more coverage that the basic stuff all works. In particular, if we could get the benchmark that Phoronix and others keep pointing at, that'd be nice. Speaking of which, have you checked the performance of some of the basic benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC there? I'd be interested to see the numbers.> > Yours, > Andrey Bokhanko > =============> Software Engineer > Intel Compiler Team > Intel > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/e6bb5285/attachment.html>
C Bergström
2015-Apr-30 22:26 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
I'm trimming everything - sorry too hard to manage the thread in my current email client -- 1) I'd rather see a configure time option to change the name rather than just switching it. It's not user facing and who really cares what the name is. (I don't) It's one more change for others who have established naming (Intel) to have to carry a patch. (I'd like to play nice here.. UH, PathScale, foobar may also want to use a different name.. etc) 2) Benchmarks - There's SPEC OMP2012, but I'm not sure if a gcc vs llvm comparison is really going to stress the runtime sufficiently enough to play the blame game. The retired OMP benchmark may use a limited enough subset of features to work with llvm+gomp||iomp.. (That way you could do a 1:1 comparison) - If that does work I'm not yet confident it would expose any real performance issues in the runtime. (You'd need to test it on a system with *A LOT* of cores) There are lowering differences between the internal API as well.. Ancedotal evidence - Intel's runtime (essentially the same code as "llvm omp") is used by Intel for OMP SPEC submissions as compared to nobody publishing record setting performance with gomp...
Jack Howarth
2015-Apr-30 22:41 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
On Thu, Apr 30, 2015 at 5:51 PM, Chandler Carruth <chandlerc at google.com> wrote:> On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: > >> All, >> >> I'd like to resurrect the discussion on replacing libgomp with libiomp as >> the default OpenMP runtime library linked with -fopenmp. >> > > Just for the record, I'm really excited to see this. =] > > >> We are very close to getting *full* OpenMP 3.1 specification supported in >> clang (only one (!) clause is not implemented yet, and the patch is already >> sent for review today: http://reviews.llvm.org/D9370). This >> implementation generates Intel API library calls; thus, it can't be used >> with libgomp and it is simply logical to link a compatible runtime >> (libiomp) instead. >> > > Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] > > Also, for the record, I'm really excited to see the progress here as well. > > >> Chandler? >> > > Hi! ;] > > I totally agree, I think things are way better now. I generally support > the direction. I think there are a few things I'd suggest we do as part of > the process, but I think these are really small and just about "how" we > switch. > > 1) I completely agree with the comments some others have made about us > needing to make it clear that this isn't some Intel-only thing, its the > LLVM OpenMP runtime. Some suggestions that I think would make sense to help > here: > - I agree with finding some non-Intel folks to add as explicit code > owners. I don't know who has been sufficiently involved, but if Hal makes > sense, awesome. > - Clearly updating the readme and such would be appropriate. > - I suspect we should change the name of the installed library. 'libiomp' > is pretty clearly the Intel library. We could continue in the grand > tradition of LLVM naming conventions and use 'libllomp'? Of course, we > should install symlinks under the name 'libiomp' if needed for existing > users to not be broken. > - Any other changes? > > 2) I think we need to update the instructions for checking out LLVM and > all the tools to include checking out the openmp project. I'm planning to > try it out in a bit. > > 3) It would be nice to get at least one boring benchmark into the > test-suite that uses OpenMP just so there's more coverage that the basic > stuff all works. In particular, if we could get the benchmark that Phoronix > and others keep pointing at, that'd be nice. > > > Attached are two logs, taskbench_clang_3.7.log and taskbench_gcc_5.1.log,with the output from the task_bench, task_firstpriv_bench and taskwait_bench benchmarks run on x86_64-apple-darwin14 using an early 2008 MacPro with dual 2.8 GHz quad-Xeon processors and 10 Gb of memory. The clang 3.7svn compiler was current trunk with the remaining two OPENMP patches on cfe-commits added to the build. The gcc compiler is release 5.1.0. In both cases, the -O3 -fopenmp flags were used. The taskbench-1.0-20110715 release was used for the benchmark sources. Speaking of which, have you checked the performance of some of the basic> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC > there? I'd be interested to see the numbers. > > >> >> Yours, >> Andrey Bokhanko >> =============>> Software Engineer >> Intel Compiler Team >> Intel >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/b79f5307/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: taskbench_clang_3.7.log Type: application/octet-stream Size: 10216 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/b79f5307/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: taskbench_gcc_5.1.log Type: application/octet-stream Size: 9909 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/b79f5307/attachment-0001.obj>
Jack Howarth
2015-Apr-30 23:29 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
On Thu, Apr 30, 2015 at 5:51 PM, Chandler Carruth <chandlerc at google.com> wrote:> On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: > >> All, >> >> I'd like to resurrect the discussion on replacing libgomp with libiomp as >> the default OpenMP runtime library linked with -fopenmp. >> > > Just for the record, I'm really excited to see this. =] > > >> We are very close to getting *full* OpenMP 3.1 specification supported in >> clang (only one (!) clause is not implemented yet, and the patch is already >> sent for review today: http://reviews.llvm.org/D9370). This >> implementation generates Intel API library calls; thus, it can't be used >> with libgomp and it is simply logical to link a compatible runtime >> (libiomp) instead. >> > > Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] > > Also, for the record, I'm really excited to see the progress here as well. > > >> Chandler? >> > > Hi! ;] > > I totally agree, I think things are way better now. I generally support > the direction. I think there are a few things I'd suggest we do as part of > the process, but I think these are really small and just about "how" we > switch. > > 1) I completely agree with the comments some others have made about us > needing to make it clear that this isn't some Intel-only thing, its the > LLVM OpenMP runtime. Some suggestions that I think would make sense to help > here: > - I agree with finding some non-Intel folks to add as explicit code > owners. I don't know who has been sufficiently involved, but if Hal makes > sense, awesome. > - Clearly updating the readme and such would be appropriate. > - I suspect we should change the name of the installed library. 'libiomp' > is pretty clearly the Intel library. We could continue in the grand > tradition of LLVM naming conventions and use 'libllomp'? Of course, we > should install symlinks under the name 'libiomp' if needed for existing > users to not be broken. > - Any other changes? > > 2) I think we need to update the instructions for checking out LLVM and > all the tools to include checking out the openmp project. I'm planning to > try it out in a bit. > > 3) It would be nice to get at least one boring benchmark into the > test-suite that uses OpenMP just so there's more coverage that the basic > stuff all works. In particular, if we could get the benchmark that Phoronix > and others keep pointing at, that'd be nice. > > > Speaking of which, have you checked the performance of some of the basic > benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC > there? I'd be interested to see the numbers. >Another set of benchmark numbers are attached in openmpbench_C_v3_clang-3.7.log and openmpbench_C_v3_gcc_5.1.log using the schedbench, syncbench and taskbench compiled with the default -O1 optimization using the clang 3.7svn trunk with the two remaining OPENMP patches from cfe-commits and the gcc 5.1.0 release compiler. The OMP_NUM_THREADS=4 is set before each set of runs which were performed on x86_64-apple-darwin14 using a early 2008 MacPro with dual 2.8 GHz quad-core Xeon processors and 10 Gb of memory. The benchmark is detailed at https://www.epcc.ed.ac.uk/research/computing/performance-characterisation-and-benchmarking/epcc-openmp-micro-benchmark-suite .> > > >> >> Yours, >> Andrey Bokhanko >> =============>> Software Engineer >> Intel Compiler Team >> Intel >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/d6d0ce27/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: openmpbench_C_v3_clang-3.7.log Type: application/octet-stream Size: 18318 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/d6d0ce27/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: openmpbench_C_v3_gcc_5.1.log Type: application/octet-stream Size: 18498 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/d6d0ce27/attachment-0001.obj>
Andrey Bokhanko
2015-May-01 08:09 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
Hal, On Thu, Apr 30, 2015 at 5:06 PM, Hal Finkel <hfinkel at anl.gov> wrote:> We need to get the build system integration committed and the buildbots > updated to compile it >If you are speaking on libiomp buidbots, they are already established: http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/c17880e5/attachment.html>
Andrey Bokhanko
2015-May-01 08:13 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
Jack, Thanks for running the test suite! I wonder how a *single* test passed with libgomp, given that no real OMP runtime calls are generated if clang targets libgomp... My educated guess is that compiler simply ignores all OMP pragmas, a test still compiles and runs correctly (which is a property of OMP specification) and the test says "oh! omp parallel for is working just fine!". Andrey On Thu, Apr 30, 2015 at 5:23 PM, Jack Howarth < howarth.mailing.lists at gmail.com> wrote:> The current test suite status on x86_64-apple-darwin14, with the > proposed patch from > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128219.html > applied to current cfe trunk, is quite respectable.... > > Summary: > S Number of tested Open MP constructs: 62 > S Number of used tests: 123 > S Number of failed tests: 16 > S Number of successful tests: 107 > S + from this were verified: 106 > > Normal tests: > N Number of failed tests: 8 > N + from this fail compilation: 1 > N + from this timed out 0 > N Number of successful tests: 54 > N + from this were verified: 54 > > Orphaned tests: > O Number of failed tests: 8 > O + from this fail compilation: 0 > O + from this timed out 0 > O Number of successful tests: 53 > O + from this were verified: 52 > > for 'make ctest' using "-fopenmp=libiomp5 -Xclang -fopenmp=libiomp5 > -L/sw/opt/llvm-3.7.0/lib -lm -O3". Whereas for libgomp, the results are > pitiful.... > > Summary: > S Number of tested Open MP constructs: 62 > S Number of used tests: 123 > S Number of failed tests: 30 > S Number of successful tests: 93 > S + from this were verified: 12 > > Normal tests: > N Number of failed tests: 15 > N + from this fail compilation: 0 > N + from this timed out 0 > N Number of successful tests: 47 > N + from this were verified: 6 > > Orphaned tests: > O Number of failed tests: 15 > O + from this fail compilation: 0 > O + from this timed out 0 > O Number of successful tests: 46 > O + from this were verified: 6 > > when using "-fopenmp=libgomp -Xclang -fopenmp=libgomp -L/sw/lib/gcc5/lib > -lm -O3 -Wl,-no_compact_unwind". So we can't get much more broken that the > current behavior with libgomp. > Jack > > On Thu, Apr 30, 2015 at 9:49 AM, Andrey Bokhanko <andreybokhanko at gmail.com > > wrote: > >> All, >> >> I'd like to resurrect the discussion on replacing libgomp with libiomp as >> the default OpenMP runtime library linked with -fopenmp. >> >> For reference, the previous discussion is accessible there: >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 >> >> We are very close to getting *full* OpenMP 3.1 specification supported in >> clang (only one (!) clause is not implemented yet, and the patch is already >> sent for review today: http://reviews.llvm.org/D9370). This >> implementation generates Intel API library calls; thus, it can't be used >> with libgomp and it is simply logical to link a compatible runtime >> (libiomp) instead. >> >> Last time Chandler objected against doing this, and gave a good (and >> proper!) scolding. Let me quote his objections along with updates on >> current state of things: >> >> - This library is not being developed as an active part of the LLVM >> community, even if it is checked into SVN as part of the LLVM project and >> under its license. See r197914 where there is a code drop of many months >> worth of development with *no* change log, attribution, information, or >> other participation in any part of the community. >> >> >> Now it is actively developed by several members of the community. Changes >> are committed in small patches. See "openmp-commits" mailing list ( >> http://lists.cs.uiuc.edu/pipermail/openmp-commits/) for details. >> >> >> - There has been essentially *zero* discussion with the rest of the clang >> or llvm community about this library. There are separate mailing lists >> which have nearly no traffic since the code drop. >> >> >> Nowadays the traffic, while less than on llvm-dev mailing list >> (understandably so :-)) is far from being "zero". Discussions happen all >> the time. See the list archives for details ( >> http://lists.cs.uiuc.edu/pipermail/openmp-dev/). >> >> >> - There has been no effort to make this library even work properly with >> Clang as a host compiler. See the copious notes that only Clang 3.3 is >> supported, and that not full featured. >> >> >> This is fixed. >> >> >> - The build system is totally disjoint from LLVM's, in fact it is an >> entirely custom Perl build system that is unlike anything in use by the >> LLVM project. >> >> >> The build system is full re-written and now cmake-based. The last >> remaining step (integration into overall llvm build system) is about to be >> done by any day now ( >> http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500 >> ). >> >> >> - There are *zero tests* in the open source repository!!!! This is even >> called out in the original submission and on the primary website. We simply >> *cannot* ship and link against a runtime library which has no tests! >> >> >> UofHouston contributed a comprehensive test suite: >> http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/. >> >> >> - No part of this library has gone through an LLVM release process >> either, not even as a "new" or "beta" project. >> >> >> The whole library is a part of two last llvm releases: 3.5 and 3.6. >> >> >> Thus, I believe all of Chandler's concerns are resolved, and it is >> finally a good time time to switch to libiomp as default OpenMP library. >> >> >> Anyone who supports this? >> >> >> Anyone who disagrees? >> >> >> Chandler? >> >> Yours, >> Andrey Bokhanko >> =============>> Software Engineer >> Intel Compiler Team >> Intel >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/17f24e66/attachment.html>
Andrey Bokhanko
2015-May-01 08:45 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
Chandler, Thanks for the reply -- I always included you in libiomp supporters camp; it is good to see I wasn't mistaken! ;-) On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at google.com> wrote:> Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] >No, sorry. libgomp doesn't support Intel API and clang generates Intel API calls only -- as simple as that. Someday someone may implement generation of GNU API calls as well, but this is a separate big task that, IMHO, doesn't serve any real purpose -- and potentially introduces nasty GPL-related legal issues. There is an option to choose what library clang links (-fopenmp={libiomp|libgomp}), though.> I totally agree, I think things are way better now. I generally support > the direction. I think there are a few things I'd suggest we do as part of > the process, but I think these are really small and just about "how" we > switch. > > 1) I completely agree with the comments some others have made about us > needing to make it clear that this isn't some Intel-only thing, its the > LLVM OpenMP runtime. Some suggestions that I think would make sense to help > here: > - I agree with finding some non-Intel folks to add as explicit code > owners. I don't know who has been sufficiently involved, but if Hal makes > sense, awesome. >This really belongs to a separate thread ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html); see my answer there in a couple of minutes.> - Clearly updating the readme and such would be appropriate. > - I suspect we should change the name of the installed library. 'libiomp' > is pretty clearly the Intel library. We could continue in the grand > tradition of LLVM naming conventions and use 'libllomp'? Of course, we > should install symlinks under the name 'libiomp' if needed for existing > users to not be broken. > - Any other changes? >Adding openmp-dev list (in retrospect, should have been done at the very start...), Jim Cownie and Andrey Churbanov.> 2) I think we need to update the instructions for checking out LLVM and > all the tools to include checking out the openmp project. I'm planning to > try it out in a bit. >Cool! Thank you!> 3) It would be nice to get at least one boring benchmark into the > test-suite that uses OpenMP just so there's more coverage that the basic > stuff all works. In particular, if we could get the benchmark that Phoronix > and others keep pointing at, that'd be nice. >Speaking of which, have you checked the performance of some of the basic> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC > there? I'd be interested to see the numbers. >This is very tricky for me -- I'm employed by a CPU vendor (Intel), and we have very strict rules and long processes for publishing benchmark results. I simply can't run a benchmark and say: "hey! clang has this number and gcc has that number". The only thing I can share is that we do tested SPEC OMP2012 ( https://www.spec.org/omp2012/), which is the industry standard for OMP benchmarks, on a non-server class Darwin machine, and the results are quite good and comparable with other compilers. Speaking on Phoronix, two benchmarks where clang always lose due to lack of OpenMP are "John the Ripper" ( http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3) and ImageMagick -- though latter is not included in most recent "clang vs gcc" comparison. Is there a generous soul (not employed by a CPU vendor :-)) willing to run "John the Ripper" with "clang -fopenmp=libiomp5 -Xclang -fopenmp=libiomp5 -lm -O3" and compare results with "clang -O3"? Also, Jack Howarth did testing with some other benchmarks, and it is nice to see that clang + libiomp compare quite well (to say it mildly ;-)) with gcc + libgomp! Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/30c3c3cc/attachment.html>
Jack Howarth
2015-May-01 17:46 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
On Thu, Apr 30, 2015 at 5:51 PM, Chandler Carruth <chandlerc at google.com> wrote:> On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: > >> All, >> >> I'd like to resurrect the discussion on replacing libgomp with libiomp as >> the default OpenMP runtime library linked with -fopenmp. >> > > Just for the record, I'm really excited to see this. =] > > >> We are very close to getting *full* OpenMP 3.1 specification supported in >> clang (only one (!) clause is not implemented yet, and the patch is already >> sent for review today: http://reviews.llvm.org/D9370). This >> implementation generates Intel API library calls; thus, it can't be used >> with libgomp and it is simply logical to link a compatible runtime >> (libiomp) instead. >> > > Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] > > Also, for the record, I'm really excited to see the progress here as well. > > >> Chandler? >> > > Hi! ;] > > I totally agree, I think things are way better now. I generally support > the direction. I think there are a few things I'd suggest we do as part of > the process, but I think these are really small and just about "how" we > switch. > > 1) I completely agree with the comments some others have made about us > needing to make it clear that this isn't some Intel-only thing, its the > LLVM OpenMP runtime. Some suggestions that I think would make sense to help > here: > - I agree with finding some non-Intel folks to add as explicit code > owners. I don't know who has been sufficiently involved, but if Hal makes > sense, awesome. > - Clearly updating the readme and such would be appropriate. > - I suspect we should change the name of the installed library. 'libiomp' > is pretty clearly the Intel library. We could continue in the grand > tradition of LLVM naming conventions and use 'libllomp'? Of course, we > should install symlinks under the name 'libiomp' if needed for existing > users to not be broken. > - Any other changes? > >Is this naming issue so serious that it will be blocker for the current patches to enabled the openmp build from within llvm/projects? Can't we just proceed with the current library name until the top-level openmp build infrastructure added and the switch of the default for -fopenmp to libiomp5 is made. It seems more sensible to stabilize the openmp support first and then revisit the naming issue in a couple of weeks. 2) I think we need to update the instructions for checking out LLVM and all> the tools to include checking out the openmp project. I'm planning to try > it out in a bit. > > 3) It would be nice to get at least one boring benchmark into the > test-suite that uses OpenMP just so there's more coverage that the basic > stuff all works. In particular, if we could get the benchmark that Phoronix > and others keep pointing at, that'd be nice. > > > Speaking of which, have you checked the performance of some of the basic > benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC > there? I'd be interested to see the numbers. > > >> >> Yours, >> Andrey Bokhanko >> =============>> Software Engineer >> Intel Compiler Team >> Intel >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/1838e7f9/attachment.html>
Richard Smith
2015-May-01 18:31 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
On Thu, Apr 30, 2015 at 2:51 PM, Chandler Carruth <chandlerc at google.com> wrote:> On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: > >> All, >> >> I'd like to resurrect the discussion on replacing libgomp with libiomp as >> the default OpenMP runtime library linked with -fopenmp. >> > > Just for the record, I'm really excited to see this. =] > > >> We are very close to getting *full* OpenMP 3.1 specification supported in >> clang (only one (!) clause is not implemented yet, and the patch is already >> sent for review today: http://reviews.llvm.org/D9370). This >> implementation generates Intel API library calls; thus, it can't be used >> with libgomp and it is simply logical to link a compatible runtime >> (libiomp) instead. >> > > Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] > > Also, for the record, I'm really excited to see the progress here as well. > > >> Chandler? >> > > Hi! ;] > > I totally agree, I think things are way better now. I generally support > the direction. I think there are a few things I'd suggest we do as part of > the process, but I think these are really small and just about "how" we > switch. > > 1) I completely agree with the comments some others have made about us > needing to make it clear that this isn't some Intel-only thing, its the > LLVM OpenMP runtime. Some suggestions that I think would make sense to help > here: > - I agree with finding some non-Intel folks to add as explicit code > owners. I don't know who has been sufficiently involved, but if Hal makes > sense, awesome. > - Clearly updating the readme and such would be appropriate. > - I suspect we should change the name of the installed library. 'libiomp' > is pretty clearly the Intel library. We could continue in the grand > tradition of LLVM naming conventions and use 'libllomp'? Of course, we > should install symlinks under the name 'libiomp' if needed for existing > users to not be broken. >Just some bikeshed-painting: if we're expecting each compiler that uses the library to distribute a separate copy as part of that compiler's runtime, then I think the best name for clang to use for the library would probably be libclang_rt.omp-<arch> or libclang_rt.openmp-<arch> (as we do for all our other runtime libraries). If we expect this to be installed somewhere central on the system and shared by different compilers and different versions of the same compiler, then libllomp or similar seems reasonable to me. What's the intended distribution model here? How stable is the ABI? - Any other changes?> > 2) I think we need to update the instructions for checking out LLVM and > all the tools to include checking out the openmp project. I'm planning to > try it out in a bit. > > 3) It would be nice to get at least one boring benchmark into the > test-suite that uses OpenMP just so there's more coverage that the basic > stuff all works. In particular, if we could get the benchmark that Phoronix > and others keep pointing at, that'd be nice. > > > Speaking of which, have you checked the performance of some of the basic > benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC > there? I'd be interested to see the numbers. > > >> >> Yours, >> Andrey Bokhanko >> =============>> Software Engineer >> Intel Compiler Team >> Intel >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/ec22f5b1/attachment.html>
Andrey Bokhanko
2015-May-02 20:18 UTC
[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
All, Let me summarize the discussion so far: 1) It seems everyone agree that libiomp (by whatever name it will be known) should be default library for -fopenmp option. Yay! 2) Some people are concerned that libomp's readme file doesn't express its multi-platform nature. As Jim Cownie pointed out, developers who actually ported the library to non-x86 platforms are most knowledgable on state of things for each particular platform, and should update readme file themselves. 3) Some people believe that libiomp is not a proper name anymore and should be changed. I'm not a library expert, so really don't know. However, this means that we should flip default library setting ASAP. Why? Because now "libiomp5" is a user-visible name (one has to use "-fopenmp=libiomp5" to enable OpenMP in clang) and the sooner it will become non user-visible, the better. Any objections here? Andrey On Thu, Apr 30, 2015 at 4:49 PM, Andrey Bokhanko <andreybokhanko at gmail.com> wrote:> All, > > I'd like to resurrect the discussion on replacing libgomp with libiomp as > the default OpenMP runtime library linked with -fopenmp. > > For reference, the previous discussion is accessible there: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 > > We are very close to getting *full* OpenMP 3.1 specification supported in > clang (only one (!) clause is not implemented yet, and the patch is already > sent for review today: http://reviews.llvm.org/D9370). This implementation > generates Intel API library calls; thus, it can't be used with libgomp and > it is simply logical to link a compatible runtime (libiomp) instead. > > Last time Chandler objected against doing this, and gave a good (and > proper!) scolding. Let me quote his objections along with updates on current > state of things: > > - This library is not being developed as an active part of the LLVM > community, even if it is checked into SVN as part of the LLVM project and > under its license. See r197914 where there is a code drop of many months > worth of development with *no* change log, attribution, information, or > other participation in any part of the community. > > > Now it is actively developed by several members of the community. Changes > are committed in small patches. See "openmp-commits" mailing list > (http://lists.cs.uiuc.edu/pipermail/openmp-commits/) for details. > > > - There has been essentially *zero* discussion with the rest of the clang or > llvm community about this library. There are separate mailing lists which > have nearly no traffic since the code drop. > > > Nowadays the traffic, while less than on llvm-dev mailing list > (understandably so :-)) is far from being "zero". Discussions happen all the > time. See the list archives for details > (http://lists.cs.uiuc.edu/pipermail/openmp-dev/). > > > - There has been no effort to make this library even work properly with > Clang as a host compiler. See the copious notes that only Clang 3.3 is > supported, and that not full featured. > > > This is fixed. > > > - The build system is totally disjoint from LLVM's, in fact it is an > entirely custom Perl build system that is unlike anything in use by the LLVM > project. > > > The build system is full re-written and now cmake-based. The last remaining > step (integration into overall llvm build system) is about to be done by any > day now > (http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500). > > > - There are *zero tests* in the open source repository!!!! This is even > called out in the original submission and on the primary website. We simply > *cannot* ship and link against a runtime library which has no tests! > > > UofHouston contributed a comprehensive test suite: > http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/. > > > - No part of this library has gone through an LLVM release process either, > not even as a "new" or "beta" project. > > > The whole library is a part of two last llvm releases: 3.5 and 3.6. > > > Thus, I believe all of Chandler's concerns are resolved, and it is finally a > good time time to switch to libiomp as default OpenMP library. > > > Anyone who supports this? > > > Anyone who disagrees? > > > Chandler? > > > Yours, > Andrey Bokhanko > =============> Software Engineer > Intel Compiler Team > Intel >
Joerg Sonnenberger
2015-May-02 23:09 UTC
[LLVMdev] [cfe-dev] libiomp, not libgomp as default library linked with -fopenmp
On Sat, May 02, 2015 at 11:18:35PM +0300, Andrey Bokhanko wrote:> 3) Some people believe that libiomp is not a proper name anymore and > should be changed. I'm not a library expert, so really don't know. > However, this means that we should flip default library setting ASAP. > Why? Because now "libiomp5" is a user-visible name (one has to use > "-fopenmp=libiomp5" to enable OpenMP in clang) and the sooner it will > become non user-visible, the better. Any objections here?Switch the library name together with the default value for clang. That seems like to the way forward. It doesn't break existing users, since they would still be using -fopenmp=libiomp5 and it doesn't introduce a surprise for new users after the lib name change. Joerg
Apparently Analagous Threads
- [LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
- [LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
- [LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
- [LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
- [LLVMdev] libiomp, not libgomp as default library linked with -fopenmp