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

[C Bergström]

While OpenMP is very explicit in nature - some compilers may not turn
on advanced analysis and become really aggressive with performance
until -O2 or -O3 (all depends on the compiler).

Benchmarks at -O1 may not have any value.. be careful of using weak comparisons.

On Fri, May 1, 2015 at 6:29 AM, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
>
>
> 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
>>
>