[Llvm-bgq-discuss] Status of OpenMP support in BG/Q

[Erik Schnetter]

A decade ago, we were forced to support many different compilers in Cactus, mostly because every supercomputer architecture came with its own compiler. These days, we support mostly GCC, Intel, and IBM's compilers, since the other compilers are too far behind, be it in terms of features, producing performant code, or not producing ICEs. Since Clang is so similar to GCC in its user interface, supporting it is almost trivial.

Portability between different architectures is very important to us. IBM's compilers are currently causing the most trouble for us since they have weird restrictions and bugs, and Clang/LLVM is correcting errors and adding features at a much greater speed than xlC.

The next infrastructure update of Cactus is very likely to use some C++11 features, either directly, or via threading or communication libraries that it uses.

-erik

On Feb 6, 2014, at 12:24 , Jeff Hammond <jhammond at anl.gov> wrote:

> In general, ALCF finds that -O5 is not worthwhile and often worse than
> -O3.  The only exceptions of which we are aware are when the user has
> tuned the code to an extreme degree - e.g. manual unrolling, blocking
> for cache, vector intrinsics.
> 
> I would strongly encourage you to let IBM know that you're abandoning
> it due to their lack of C++11 support.  It is important for them to
> understand that their development model for XLC on Blue Gene harms
> users in significant ways.
> 
> Jeff
> 
> On Thu, Feb 6, 2014 at 9:55 AM, Schlottke, Michael
> <m.schlottke at fz-juelich.de> wrote:
>> Hi Hal,
>> 
>> Since the clang-omp team announced support for Clang 3.4 today I was
>> wondering what the status is of OpenMP support for clang on BGQ? Are there
>> any efforts going in this direction? And if not, is it due to a lack of
>> interest or because it is too difficult/time consuming to do?
>> 
>> I am asking since we finished some performance tests of mpixlcxx vs
>> mpiclang++ on the BGQ in Jülich and found that even with -O5 for the XL
>> compiler, the single-core runtime of the clang-compiled executables is
>> usually only less than 5% higher. We are therefore thinking about dropping
>> support for IBM's XL entirely, since it's the only compiler holding us back
>> from C++11.
>> 
>> Regards,
>> 
>> Michael
>> 
>> P. S. : If anyone is interested in the above-mentioned numbers, please let
>> me know.
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------------------------
>> ------------------------------------------------------------------------------------------------
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich
>> Sitz der Gesellschaft: Juelich
>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>> Prof. Dr. Sebastian M. Schmidt
>> ------------------------------------------------------------------------------------------------
>> ------------------------------------------------------------------------------------------------
>> 
>> 
>> _______________________________________________
>> llvm-bgq-discuss mailing list
>> llvm-bgq-discuss at lists.alcf.anl.gov
>> https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss
>> 
> 
> 
> 
> -- 
> Jeff Hammond
> Argonne Leadership Computing Facility
> University of Chicago Computation Institute
> jhammond at anl.gov / jhammond at uchicago.edu / (630) 252-5381
> http://www.linkedin.com/in/jeffhammond
> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
> _______________________________________________
> llvm-bgq-discuss mailing list
> llvm-bgq-discuss at lists.alcf.anl.gov
> https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss

-- 
Erik Schnetter <schnetter at gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.alcf.anl.gov/pipermail/llvm-bgq-discuss/attachments/20140206/16d33a24/attachment.pgp>