[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp

[Jack Howarth]

On Sat, May 2, 2015 at 4:26 PM, Andrey Bokhanko <andreybokhanko at gmail.com>
wrote:

> Jack,
>
> Thank you for measuring this!
>
> If I interpret results correctly (higher numbers = better
> performance), clang + libiomp combo produces faster (sometimes
> significantly faster) code in practically every case!
>
>
According to http://openwall.info/wiki/john/benchmarks, higher c/s rates
equals higher openmp performance. Note that they seem to value the result
from the DES crypt many/one salt over the other benchmark values and sort
their benchmark tables by that column.


> Andrey
>
>
> On Fri, May 1, 2015 at 3:26 PM, Jack Howarth
> <howarth.mailing.lists at gmail.com> wrote:
> >
> >
> > On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <
> andreybokhanko at gmail.com>
> > wrote:
> >>
> >> 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"?
> >
> >
> > Attached are preliminary benchmarking of John the Ripper 1.8.0 for clang
> > 3.7svn with the two outstanding OPENMP patches applied and for gcc 5.1.0.
> > The attached john_the_ripper_clang-3.7.log and
> john_the_ripper_gcc-5.1.log
> > files contain the benchmarks at -O2 and -O3 for each compiler. As before,
> > the runs are from x86_64-apple-darwin14 using a early 2008 MacPro with
> dual
> > 2.8GHz quad-core Xeon processors and 10 Gb of memory.
> >
> >>
> >> 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
> >>
> >>
> >> _______________________________________________
> >> 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/20150502/8a104ee5/attachment.html>