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

[Andrey Bokhanko]

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!

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
>>
>