Polly

[ghost]

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]

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
#44.

[ghost]

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]

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 #44.

—
Reply to this email directly or view it on GitHub
#44 (comment).

[ghost]

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]

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
#44 (comment).

[alexey-bataev]

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
#44 (comment).

[jcownie-intel]

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
#44 (comment).

—

Reply to this email directly or view it on GitHubhttps://github.com//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]

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
#44 (comment).

—

Reply to this email directly or view it on GitHubhttps://github.com//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]

@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?