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

[Schlottke, Michael]

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.
Our experiences are similar. However, -O5 still has a slight (tiny, really) edge over -O3 for us (at the cost, of course, of 2+ hours compile&link times…), even though we do not use any fancy manual optimizations.

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.
At the beginning of the week, we had a BG/Q Porting & Tuning workshop at the Forschungszentrum Jülich. I talked to one of the IBM representatives and even he could not explain the lackluster support for C++ in the compiler development team.

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.
We have made some good experiences with the current PGI (just released: 14.1) and Intel compilers. While the older PGI compilers still had quite a few bugs, the more recent ones do not cause any problems for us and actually found some (minor)  cases of bad programming that eluded gcc/clang.

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.
If you're looking for a move to C++11 and wonder which C++11 features are supported on the XL machines… well, good luck with that. I wrote a small collection of tests that check if a compiler supports individual C++11 features (https://github.com/sloede/cxx11tests) and I was surprised by how little is actually implemented in XL. For instance, the XL 12.1 reference claims that valid 'constexpr' syntax is supported, which is not true for at least one example (constexpr float arrays). Although the tests are far from complete, they might give you a good overview of what's supported and what isn't.

Regards,

Michael

On Feb 6, 2014, at 19:33 , Erik Schnetter wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alcf.anl.gov/pipermail/llvm-bgq-discuss/attachments/20140207/c4a27d74/attachment-0001.html>