<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 2, 2015 at 4:26 PM, Andrey Bokhanko <span dir="ltr"><<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Jack,<br>
<br>
Thank you for measuring this!<br>
<br>
If I interpret results correctly (higher numbers = better<br>
performance), clang + libiomp combo produces faster (sometimes<br>
significantly faster) code in practically every case!<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>According to <a href="http://openwall.info/wiki/john/benchmarks">http://openwall.info/wiki/john/benchmarks</a>, 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888">
Andrey<br>
</font></span><div class=""><div class="h5"><br>
<br>
On Fri, May 1, 2015 at 3:26 PM, Jack Howarth<br>
<<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com">andreybokhanko@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Chandler,<br>
>><br>
>> Thanks for the reply -- I always included you in libiomp supporters camp;<br>
>> it is good to see I wasn't mistaken! ;-)<br>
>><br>
>> On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
>> wrote:<br>
>>><br>
>>> Is there no way to support libgomp here as well? I don't say this to hold<br>
>>> up changing the defaults in any way, just curious. =]<br>
>><br>
>><br>
>> No, sorry. libgomp doesn't support Intel API and clang generates Intel API<br>
>> calls only -- as simple as that. Someday someone may implement generation of<br>
>> GNU API calls as well, but this is a separate big task that, IMHO, doesn't<br>
>> serve any real purpose -- and potentially introduces nasty GPL-related legal<br>
>> issues.<br>
>><br>
>> There is an option to choose what library clang links<br>
>> (-fopenmp={libiomp|libgomp}), though.<br>
>><br>
>>><br>
>>> I totally agree, I think things are way better now. I generally support<br>
>>> the direction. I think there are a few things I'd suggest we do as part of<br>
>>> the process, but I think these are really small and just about "how" we<br>
>>> switch.<br>
>>><br>
>>> 1) I completely agree with the comments some others have made about us<br>
>>> needing to make it clear that this isn't some Intel-only thing, its the LLVM<br>
>>> OpenMP runtime. Some suggestions that I think would make sense to help here:<br>
>>> - I agree with finding some non-Intel folks to add as explicit code<br>
>>> owners. I don't know who has been sufficiently involved, but if Hal makes<br>
>>> sense, awesome.<br>
>><br>
>><br>
>> This really belongs to a separate thread<br>
>> (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html</a>); see my<br>
>> answer there in a couple of minutes.<br>
>><br>
>>><br>
>>> - Clearly updating the readme and such would be appropriate.<br>
>>> - I suspect we should change the name of the installed library. 'libiomp'<br>
>>> is pretty clearly the Intel library. We could continue in the grand<br>
>>> tradition of LLVM naming conventions and use 'libllomp'? Of course, we<br>
>>> should install symlinks under the name 'libiomp' if needed for existing<br>
>>> users to not be broken.<br>
>>> - Any other changes?<br>
>><br>
>><br>
>> Adding openmp-dev list (in retrospect, should have been done at the very<br>
>> start...), Jim Cownie and Andrey Churbanov.<br>
>><br>
>>><br>
>>> 2) I think we need to update the instructions for checking out LLVM and<br>
>>> all the tools to include checking out the openmp project. I'm planning to<br>
>>> try it out in a bit.<br>
>><br>
>><br>
>> Cool! Thank you!<br>
>><br>
>>><br>
>>> 3) It would be nice to get at least one boring benchmark into the<br>
>>> test-suite that uses OpenMP just so there's more coverage that the basic<br>
>>> stuff all works. In particular, if we could get the benchmark that Phoronix<br>
>>> and others keep pointing at, that'd be nice.<br>
>><br>
>><br>
>>> Speaking of which, have you checked the performance of some of the basic<br>
>>> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC<br>
>>> there? I'd be interested to see the numbers.<br>
>><br>
>><br>
>> This is very tricky for me -- I'm employed by a CPU vendor (Intel), and we<br>
>> have very strict rules and long processes for publishing benchmark results.<br>
>> I simply can't run a benchmark and say: "hey! clang has this number and gcc<br>
>> has that number".<br>
>><br>
>> The only thing I can share is that we do tested SPEC OMP2012<br>
>> (<a href="https://www.spec.org/omp2012/" target="_blank">https://www.spec.org/omp2012/</a>), which is the industry standard for OMP<br>
>> benchmarks, on a non-server class Darwin machine, and the results are quite<br>
>> good and comparable with other compilers.<br>
>><br>
>> Speaking on Phoronix, two benchmarks where clang always lose due to lack<br>
>> of OpenMP are "John the Ripper"<br>
>> (<a href="http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3" target="_blank">http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3</a>)<br>
>> and ImageMagick -- though latter is not included in most recent "clang vs<br>
>> gcc" comparison.<br>
>><br>
>> Is there a generous soul (not employed by a CPU vendor :-)) willing to run<br>
>> "John the Ripper" with "clang -fopenmp=libiomp5 -Xclang -fopenmp=libiomp5<br>
>> -lm -O3" and compare results with "clang -O3"?<br>
><br>
><br>
> Attached are preliminary benchmarking of John the Ripper 1.8.0 for clang<br>
> 3.7svn with the two outstanding OPENMP patches applied and for gcc 5.1.0.<br>
> The attached john_the_ripper_clang-3.7.log and  john_the_ripper_gcc-5.1.log<br>
> files contain the benchmarks at -O2 and -O3 for each compiler. As before,<br>
> the runs are from x86_64-apple-darwin14 using a early 2008 MacPro with dual<br>
> 2.8GHz quad-core Xeon processors and 10 Gb of memory.<br>
><br>
>><br>
>> Also, Jack Howarth did testing with some other benchmarks, and it is nice<br>
>> to see that clang + libiomp compare quite well (to say it mildly ;-)) with<br>
>> gcc + libgomp!<br>
>><br>
>> Andrey<br>
>><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>