<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 22, 2018 at 8:09 AM, Joachim Protze via Openmp-dev <span dir="ltr"><<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, different proposal:<br>
<br>
Many computing centers carefully provide separate tool chains for different compilers used on their clusters based on module system or similar approaches.<br>
<br>
I also think, that in the near future several tools will integrate the LLVM/OpenMP runtime into their build to enable their tool to work with applications built with older compilers coming without OMPT interface.<br>
Hopefully this will be solved within the next years :) But experience shows that HPC machines tend to run with quite old software stack, so it could take another 5-10 years :(<br></blockquote><div><br></div><div>I spent 5 years of my life in software support for a major HPC center and I don't think this is a fair characterization. It is true that some of the more exotic machines place limits on the software upgrades, but if we ignore IBM Blue Gene/Q and Fujitsu K, there is no issue installing the latest everything. The support staff might not do it at the pace you like because of finite resources, or because the majority of users do not care about GCC 8.1 or Intel 18.0.2 compilers, but if there is demonstrable need for new software, it is not a technical problem to get it installed.</div><div><br></div><div>If you are struggling with unhelpful HPC center support staff not installing needed software updates, I can provide advice on how to engage them in a way that is more likely to lead to positive results.</div><div><br></div><div>Jeff</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A configure switch might provide the ability to turn off kmp or gomp interface in these module environments. So, if the sysadmin compiles the runtime for the gcc toolchain, he would only activate the gomp interface. Based on this switch a more detailed support level of OMPT callbacks might be announced to the tool.<br>
Default for this switch would be of cause kmp+gomp.<br>
<br>
Best<span class="HOEnZb"><font color="#888888"><br>
Joachim</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 06/20/2018 07:32 PM, Churbanov, Andrey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Doesn't sound like a good idea to me.<br>
<br>
The whole point why we have GOMP and KMP interfaces in the library is to allow same binary be used with code compiled by different compilers.<br>
<br>
You may solve one particular problem of running unit tests for an OpenMP implementation (one combination of compiler+runtime). But what if people use several OpenMP implementations to produce single application (e.g. several OpenMP-parallelized third-party libraries)? These cases may stop working or produce unexpected (or unspecified) results.<br>
<br>
I'd rather look for some other solution for the problem. E.g. always return ompt_set_sometimes when registering ompt_callback_work. Or make a tool to cope somehow with the absence of end_single event. Etc.<br>
<br>
Regards,<br>
Andrey<br>
<br>
-----Original Message-----<br>
From: Joachim Protze [mailto:<a href="mailto:protze.joachim@gmail.com" target="_blank">protze.joachim@gmail.c<wbr>om</a>]<br>
Sent: Monday, June 18, 2018 4:17 PM<br>
To: Churbanov, Andrey <<a href="mailto:Andrey.Churbanov@intel.com" target="_blank">Andrey.Churbanov@intel.com</a>><br>
Cc: <a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a><br>
Subject: Re: [Openmp-dev] kmp vs. gomp<br>
<br>
Following Michael Klemms opinion, that an OpenMP implementation consists of a fixed pair of compiler+runtime, I suggest to add a CMake flag, that selects whether the intended use of the runtime is KMP or GOMP.<br>
<br>
Based on this flag, we would provide return codes for OMPT callback registration.<br>
<br>
What do you think about this proposal?<br>
<br>
Best<br>
Joachim<br>
<br>
On 06/13/2018 03:05 PM, Churbanov, Andrey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In general, it is not possible to know which compiler used to compile the code that caused the initialization of the runtime library.<br>
It could be possible if kmp or gomp interface caused the initialization, but definitely not possible if it was omp_* call.<br>
<br>
Note also that we tentatively support case when executable linked from objects compiled by different compilers, so the library can be initialized in code compiled by one compiler and then used in the code compiled by another compiler (we do not cover all the cases of cause, but simple cases should work).<br>
<br>
-- Andrey<br>
<br>
-----Original Message-----<br>
From: Openmp-dev [mailto:<a href="mailto:openmp-dev-bounces@lists.llvm.org" target="_blank">openmp-dev-bounces@lis<wbr>ts.llvm.org</a>] On Behalf<br>
Of Joachim Protze via Openmp-dev<br>
Sent: Wednesday, June 13, 2018 12:35 AM<br>
To: <a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a><br>
Subject: [Openmp-dev] kmp vs. gomp<br>
<br>
Hi all,<br>
<br>
is there a way in the runtime to tell whether the runtime was initialized through a call to the kmp or gomp interface? As I understand the initialization, this is currently not possible.<br>
<br>
A way to implement this would be to pass a flag through __kmp_get_global_thread_id_reg to __kmp_do_serial_initialize. Would this be acceptable?<br>
<br>
The background for this question is the different behavior regarding OMPT callbacks. Specifically, gomp has currently no way to provide a callback for the single-end event.<br>
Following the specification, the runtime should return ompt_set_sometimes instead of ompt_set_always when registering ompt_callback_work knowing that the application uses the gomp interface.<br>
<br>
Best<br>
Joachim<br>
______________________________<wbr>_________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/openmp-dev</a><br>
<br>
------------------------------<wbr>------------------------------<wbr>--------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park,<br>
17 Krylatskaya Str., Bldg 4, Moscow 121614, Russian Federation<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<br>
<br>
</blockquote>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>--------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park,<br>
17 Krylatskaya Str., Bldg 4, Moscow 121614,<br>
Russian Federation<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/openmp-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div></div>