search

clang-omp / clang

clang with OpenMP 3.1 and some elements of OpenMP 4.0 support
clang-omp.github.com
Other
91 stars 15 forks source link

Polly #44

Closed ghost closed 10 years ago

ghost commented 10 years ago

The llvm and clang sources on the clang-omp git don't include polly, and polly can't be added because the version on git is out of sync with the clang-omp sources.

alexey-bataev commented 10 years ago

Try to get polly from Release 3.5, not trunk version. You can get it here http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_350/final/. Clang-omp must be compatible with this version.

Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp.

28.09.2014 23:27, justsomeone1001 пишет:

The llvm and clang sources on the clang-omp git don't include polly, and polly can't be added because the version on git is out of sync with the clang-omp sources.

— Reply to this email directly or view it on GitHub https://github.com/clang-omp/clang/issues/44.

ghost commented 10 years ago

Just to follow-up --- I was able to get clang-omp to compile either with polly, or with dragonegg, but never with both. After benchmarking some code produced with each, however, I concluded that neither book was worth the candle and dropped both of them.

alexey-bataev commented 10 years ago

Hi, could you provide some additional info on perf issues you experienced? Why do you need dragonegg?

Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp.

10.10.2014 8:56, justsomeone1001 пишет:

Closed #44 https://github.com/clang-omp/clang/issues/44.

— Reply to this email directly or view it on GitHub https://github.com/clang-omp/clang/issues/44#event-176733087.

ghost commented 10 years ago

Sure... I've been benchmarking R with different compiler and configuration options. Different BLAS's, openmp libraries, etc. The benchmarks don't just look at small repeated micro-operations, but include cut-and-pastes of real-world CPU-eating code. The results have been quite illuminating. If you contact me directly or give me your e-mail, I can send you the results for poly vs. other compiler options, or give you the raw data if you'd like.

Polly did not perform well. LLVM 3.5 with clang-omp, -O3 and link-time optimization outperformed everything else, gcc or llvm.

Dragonegg... if you do a search on stackoverflow for openmp, gcc, and mkl, you'll see a whole discussion with some Intel folks that explains why I was using that.

alexey-bataev commented 10 years ago

You can use a.bataev@gmx.com

Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp.

10.10.2014 9:53, justsomeone1001 пишет:

Sure... I've been benchmarking R with different compiler and configuration options. Different BLAS's, openmp libraries, etc. The benchmarks don't just look at small repeated micro-operations, but include cut-and-pastes of real-world CPU-eating code. The results have been quite illuminating. If you contact me directly or give me your e-mail, I can send you the results for poly vs. other compiler options, or give you the raw data if you'd like.

Polly did not perform well. LLVM 3.5 with clang-omp, -O3 and link-time optimization outperformed everything else, gcc or llvm.

Dragonegg... if you do a search on stackoverflow for openmp, gcc, and mkl, you'll see a whole discussion with some Intel folks that explains why I was using that.

— Reply to this email directly or view it on GitHub https://github.com/clang-omp/clang/issues/44#issuecomment-58615329.

alexey-bataev commented 10 years ago

It seems to me polly is not compatible with clang-omp, because it uses libgomp, a GNU OMP runtime library. clang-omp is based on libiomp5, which is official OMP runtime lib for LLVM. Though libiomp5 supports 90% of libgomp API, clang-omp uses native libiomp5 API, not libgomp, because it works faster.

Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp.

10.10.2014 10:35, Bataev, Alexey пишет:

You can use a.bataev@gmx.com Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp. 10.10.2014 9:53, justsomeone1001 пишет:

Sure... I've been benchmarking R with different compiler and configuration options. Different BLAS's, openmp libraries, etc. The benchmarks don't just look at small repeated micro-operations, but include cut-and-pastes of real-world CPU-eating code. The results have been quite illuminating. If you contact me directly or give me your e-mail, I can send you the results for poly vs. other compiler options, or give you the raw data if you'd like.

Polly did not perform well. LLVM 3.5 with clang-omp, -O3 and link-time optimization outperformed everything else, gcc or llvm.

Dragonegg... if you do a search on stackoverflow for openmp, gcc, and mkl, you'll see a whole discussion with some Intel folks that explains why I was using that.

— Reply to this email directly or view it on GitHub https://github.com/clang-omp/clang/issues/44#issuecomment-58615329.

jcownie-intel commented 10 years ago

Just to clarify what Alexey says below…

Apparently polly generates code that directly targets the interfaces of the libgomp OpenMP runtime, while clang-omp targets those provided by the LLVM OpenMP runtime (libiomp5). Therefore at first glance the two are incompatible since having more than one OpenMP runtime linked into a single process is disastrous. However, since the LLVM OpenMP runtime also provides the GOMP entrypoints it should, in fact, be possible to use Polly and clang-omp together, provided that you only link with libiomp5.so and don’t also link libgomp.so.

In summary

· Link with libiomp5.so and not with libgomp.so and you should be OK.

Extra detail if needed… Added complexities are related to the changes in the GOMP interfaces between GCC 4.8 and 4.9, which meant that for a while the LLLVM OpenMP runtime didn’t support the GCC 4.9 interfaces, (now fixed!), and assuming that Polly won’t be using GCC 4.9’s task cancellation interfaces (which we haven’t implemented because of potential performance impact even when they’re not used).

-- Jim

James Cownie james.h.cownie@intel.com SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes) Tel: +44 117 9071438

From: Alexey Bataev [mailto:notifications@github.com] Sent: Friday, October 10, 2014 9:42 AM To: clang-omp/clang Subject: Re: [clang] Polly (#44)

It seems to me polly is not compatible with clang-omp, because it uses libgomp, a GNU OMP runtime library. clang-omp is based on libiomp5, which is official OMP runtime lib for LLVM. Though libiomp5 supports 90% of libgomp API, clang-omp uses native libiomp5 API, not libgomp, because it works faster.

Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp.

10.10.2014 10:35, Bataev, Alexey пишет:

You can use a.bataev@gmx.com Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp. 10.10.2014 9:53, justsomeone1001 пишет:

Sure... I've been benchmarking R with different compiler and configuration options. Different BLAS's, openmp libraries, etc. The benchmarks don't just look at small repeated micro-operations, but include cut-and-pastes of real-world CPU-eating code. The results have been quite illuminating. If you contact me directly or give me your e-mail, I can send you the results for poly vs. other compiler options, or give you the raw data if you'd like.

Polly did not perform well. LLVM 3.5 with clang-omp, -O3 and link-time optimization outperformed everything else, gcc or llvm.

Dragonegg... if you do a search on stackoverflow for openmp, gcc, and mkl, you'll see a whole discussion with some Intel folks that explains why I was using that.

— Reply to this email directly or view it on GitHub https://github.com/clang-omp/clang/issues/44#issuecomment-58615329.

—

Reply to this email directly or view it on GitHubhttps://github.com/clang-omp/clang/issues/44#issuecomment-58627936.

Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

ghost commented 10 years ago

To clarify - I didn't have instability with Polly on. (On Mac OS, apparently you can have multiple omp libraries linked simultaneously, because of how Mac handles dynamic linking.) But performance was inferior to llvmomp with -O3. That's why I was closing a bug report about how to get Polly working consistently.

Whether Polly generates code for gomp or iomp5, the linker replaces all the gomp calls with iomp5 anyway.

I've send Alexy the benchmark testing results. Happy to try to provide mor data if it helps.

On Oct 10, 2014, at 6:22 AM, jcownie-intel notifications@github.com wrote:

Just to clarify what Alexey says below…

Apparently polly generates code that directly targets the interfaces of the libgomp OpenMP runtime, while clang-omp targets those provided by the LLVM OpenMP runtime (libiomp5). Therefore at first glance the two are incompatible since having more than one OpenMP runtime linked into a single process is disastrous. However, since the LLVM OpenMP runtime also provides the GOMP entrypoints it should, in fact, be possible to use Polly and clang-omp together, provided that you only link with libiomp5.so and don’t also link libgomp.so.

In summary

· Link with libiomp5.so and not with libgomp.so and you should be OK.

Extra detail if needed… Added complexities are related to the changes in the GOMP interfaces between GCC 4.8 and 4.9, which meant that for a while the LLLVM OpenMP runtime didn’t support the GCC 4.9 interfaces, (now fixed!), and assuming that Polly won’t be using GCC 4.9’s task cancellation interfaces (which we haven’t implemented because of potential performance impact even when they’re not used).

-- Jim

James Cownie james.h.cownie@intel.com SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes) Tel: +44 117 9071438

From: Alexey Bataev [mailto:notifications@github.com] Sent: Friday, October 10, 2014 9:42 AM To: clang-omp/clang Subject: Re: [clang] Polly (#44)

It seems to me polly is not compatible with clang-omp, because it uses libgomp, a GNU OMP runtime library. clang-omp is based on libiomp5, which is official OMP runtime lib for LLVM. Though libiomp5 supports 90% of libgomp API, clang-omp uses native libiomp5 API, not libgomp, because it works faster.

Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp.

10.10.2014 10:35, Bataev, Alexey пишет:

You can use a.bataev@gmx.com Best regards,

Alexey Bataev

Software Engineer Intel Compiler Team Intel Corp. 10.10.2014 9:53, justsomeone1001 пишет:

Sure... I've been benchmarking R with different compiler and configuration options. Different BLAS's, openmp libraries, etc. The benchmarks don't just look at small repeated micro-operations, but include cut-and-pastes of real-world CPU-eating code. The results have been quite illuminating. If you contact me directly or give me your e-mail, I can send you the results for poly vs. other compiler options, or give you the raw data if you'd like.

Polly did not perform well. LLVM 3.5 with clang-omp, -O3 and link-time optimization outperformed everything else, gcc or llvm.

Dragonegg... if you do a search on stackoverflow for openmp, gcc, and mkl, you'll see a whole discussion with some Intel folks that explains why I was using that.

— Reply to this email directly or view it on GitHub https://github.com/clang-omp/clang/issues/44#issuecomment-58615329.

—

Reply to this email directly or view it on GitHubhttps://github.com/clang-omp/clang/issues/44#issuecomment-58627936.

Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. — Reply to this email directly or view it on GitHub.

tobiasgrosser commented 9 years ago

@justsomeone1001 : I just came accross the performance issues you reported with respect to Polly and wonder if you could possibly send me your performance results for me to understand if/why Polly did not give benefits for you. There are plenty of optimizations Polly is not yet doing, so I would like to understand if this is mostly a missed optimization or rather a conceptual issue. You did not report a performance bug, did you?