<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 12/03/2017 10:09 PM, Serge Preis via
cfe-dev wrote:<br>
</div>
<blockquote cite="mid:6291512360545@webcorp03f.yandex-team.ru"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Hello,</div>
<div> </div>
<div>_Pragma("omp simd") is sematically quite different from
_Pragma("clang loop vectorize(assume_safety)"), _Pragma("GCC
ivdep") and _Pragma("vector always"), so I am not sure all
latter will work as exepected in all cases. They definitely
won't provide any vectorization guarantees which slightly defeat
the purpose of using corresponding execution policy.</div>
<div> </div>
<div>I support the idea of having OpenMP orthogonal and definitely
having -fopenmp enabled by default is not an option. Intel
compiler has separate -qopenmp-simd option which doesn't affect
performance outside explicitly marked loops,</div>
</blockquote>
<br>
A similar flag is being worked on for Clang (see
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D31417">https://reviews.llvm.org/D31417</a>).<br>
<br>
Maybe what we really need for this is some kind of '
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
#pragma GCC push_options' thing so that we can force OpenMP SIMD
support on in particular regions of code?<br>
<br>
-Hal<br>
<br>
<blockquote cite="mid:6291512360545@webcorp03f.yandex-team.ru"
type="cite">
<div> but even this is not enabled by default. I would say that
there might exist multiple implementations of unordered policy,
originally OpenMP SIMD based implementation may be more powerful
and one based on other pragmas being default, but hinting about
existence of faster option. Later on one may be brave enough to
add some SIMD template library and implement default unordered
policy using it (such implementation is possible even now using
vector types, but it will be extremely complex if attempt to
target all base data types, vector widths and target SIMD
atchitectures clang supports. Even with the library this may be
quite tedious).</div>
<div> </div>
<div>Without any standard way of expressing SIMD perallelism in
pure C++ any implementer of SIMD execution policy is to rely on
means avaialble for plaform/compiler and so it is not totaly
unnatural to ask user to enable OpenMP SIMD for efficient
support of corresponding execution policy.</div>
<div> </div>
<div>Reagrds,</div>
<div>Serge Preis</div>
<div> </div>
<div>(Who once was part of Intel Compiler Vectorizer team and
driven OpenMP SIMD efforts within icc and beyond, if anyone is
keeping track of conflicts-of-interest)</div>
<div> </div>
<div> </div>
<div>04.12.2017, 08:46, "Jeff Hammond via cfe-dev"
<a class="moz-txt-link-rfc2396E" href="mailto:cfe-dev@lists.llvm.org"><cfe-dev@lists.llvm.org></a>:</div>
<blockquote type="cite">
<div>It would be nice to keep PSTL and OpenMP orthogonal, even
if _Pragma("omp simd") does not require runtime support. It
should be trivial to use _Pragma("clang loop
vectorize(assume_safety)") instead, by wrapping all of the
different compiler vectorization pragmas in preprocessor
logic. I similarly recommend _Pragma("GCC ivdep") for GCC and
_Pragma("vector always") for ICC. While this requires
O(n_compilers) effort instead of O(1), but orthogonality is
worth it.
<div> </div>
<div>While OpenMP is vendor/compiler-agnostic, users should
not be required to use -fopenmp or similar to enable
vectorization from PSTL, nor should the compiler enable any
OpenMP pragma by default. I know of cases where merely
using the -fopenmp flag alters code generation in a
performance-visible manner, and enabling the OpenMP "simd"
pragma by default may surprise some users, particularly if
no other OpenMP pragmas are enabled by default.
<div><br>
Best,</div>
<div> </div>
<div>Jeff</div>
<div>(who works for Intel but not on any software products
and has been a heavy user of Intel PSTL since it was
released, if anyone is keeping track of
conflicts-of-interest)<br>
<br>
On Wed, Nov 29, 2017 at 4:21 AM, Kukanov, Alexey via
cfe-dev <<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>
wrote:<br>
><br>
> Hello all,<br>
><br>
> At Intel, we have developed an implementation of
C++17 execution policies<br>
> for algorithms (often referred to as Parallel STL).
We hope to contribute it<br>
> to libc++/LLVM, so would like to ask the community
for comments on this.<br>
><br>
> The code is already published at GitHub (<a
moz-do-not-send="true"
href="https://github.com/intel/parallelstl">https://github.com/intel/parallelstl</a>).<br>
> It supports the C++17 standard execution policies
(seq, par, par_unseq) as well as<br>
> the experimental unsequenced policy (unseq) for SIMD
execution. At the moment,<br>
> about half of the C++17 standard algorithms that must
support execution policies<br>
> are implemented; a few more will be ready soon, and
the work continues.<br>
> The tests that we use are also available at GitHub;
needless to say we will<br>
> contribute those as well.<br>
><br>
> The implementation is not specific to Intel’s
hardware. For thread-level parallelism<br>
> it uses TBB* (<a moz-do-not-send="true"
href="https://www.threadingbuildingblocks.org/">https://www.threadingbuildingblocks.org/</a>)
but abstracts it with<br>
> an internal API which can be implemented on top of
other threading/parallel solutions –<br>
> so it is for the community to decide which ones to
use. For SIMD parallelism<br>
> (unseq, par_unseq) we use #pragma omp simd
directives; it is vendor-neutral and<br>
> does not require any OpenMP runtime support.<br>
><br>
> The current implementation meets the spirit but not
always the letter of<br>
> the standard, because it has to be separate from but
also coexist with<br>
> implementations of standard C++ libraries. While
preparing the contribution,<br>
> we will address inconsistencies, adjust the code to
meet community standards,<br>
> and better integrate it into the standard library
code.<br>
><br>
> We are also proposing that our implementation is
included into libstdc++/GCC.<br>
> Compatibility between the implementations seems
useful as it can potentially<br>
> reduce the amount of work for everyone. We hope to
keep the code mostly identical,<br>
> and would like to know if you think it’s too
optimistic to expect.<br>
><br>
> Obviously we plan to use appropriate open source
licenses to meet the different<br>
> projects’ requirements.<br>
><br>
> We expect to keep developing the code and will take
the responsibility for<br>
> maintaining it (with community contributions, of
course). If there are other<br>
> community efforts to implement parallel algorithms,
we are willing to collaborate.<br>
><br>
> We look forward to your feedback, both for the
overall idea and – if supported –<br>
> for the next steps we should take.<br>
><br>
> Regards,<br>
> - Alexey Kukanov<br>
><br>
> * Note that TBB itself is highly portable (and ported
by community to Power and ARM<br>
> architectures) and permissively licensed, so could be
the base for the threading<br>
> infrastructure. But the Parallel STL implementation
itself does not require TBB.<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
<br>
--<br>
Jeff Hammond<br>
<a moz-do-not-send="true"
href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
<a moz-do-not-send="true"
href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a>
<div> </div>
</div>
</div>
</div>
,
<p>_______________________________________________<br>
cfe-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></p>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>