<html><head></head><body bgcolor="#FFFFFF"><div>One comment inline...<br><br>Olivier</div><div><br>On Jun 4, 2013, at 1:56 AM, "Al Grant" &lt;<a href="mailto:Al.Grant@arm.com">Al.Grant@arm.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->


<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Fixed vector widths make sense where the data is inherently some kind of fixed-sized tuple, e.g. complex numbers, or (x,y,z) or (x,y,z,w) or (r,g,b,a) etc.&nbsp;
 We see this a lot in graphics / game physics.&nbsp; A feature of such code is that the operations on each element aren’t always the same – it’s not always SIMD, sometimes it’s SISD (on one lane) or MIMD (different operations on different lanes). &nbsp;Usually we have
 3 or 4 elements (sometimes 2).&nbsp; Data type would often be float32 (I guess float64, increasingly), </span></p></div></div></blockquote><div><br></div><div>[olivier] No, it's going the other way: fp16, increasingly. &nbsp;There is effectively zero fp64 in graphics and game physics.</div><br><blockquote type="cite"><div><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">sometimes int32 or int16, which may be interpreted as Q31 or Q15.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The programmer’s understanding of what the lanes mean, and the appropriate names for the lanes, is dependent on the application.&nbsp; So one possibility here would
 be to let the user define each vector type as a struct (with all members having the same type), and invent a new annotation marking the struct as a vector – with possible effects on alignment, padding and parameter passing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">There is also a demand for math functions on short vector types – again, not just true SIMD functions but things like dot-product, or quaternion construction
 (a mixture of sin and cos).&nbsp; Some of those might be standard, some third-party.&nbsp; If the short vectors are provided as generic types (int4 / int32x4_t etc.) then that’s the obvious argument type for vectors.&nbsp; If alternatively, short vectors are provided via
 a vector annotation to structs, to allow libraries to be written generically over these types there ought to be some conversion to/from vectorized struct types.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">In the case where SIMD is being used to accelerate longer vectors then I agree that letting the compiler do the work makes more sense – but it would be useful
 to be able to have a standard way of communicating to the compiler any information that helps it optimize, e.g. asserting that vector length is a multiple of some power of 2, that there are no loop-carried dependencies etc.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Al<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Tom Scogland [mailto:tom.scogland@gmail.com]
<br>
<b>Sent:</b> 03 June 2013 23:31<br>
<b>To:</b> Timothy G Mattson<br>
<b>Cc:</b> Jeff Hammond; <a href="mailto:cplex@open-std.org">cplex@open-std.org</a>; Bill Carlson; Al Grant<br>
<b>Subject:</b> Re: [Cplex] Short SIMD vector types<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">Both OpenCL, as mentioned, and CUDA provide similarly natural short vectors through types for specific widths. &nbsp;They are far easier to manage than traditional vector intrinsics, especially for those new to SIMD programming.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">A big issue with that approach though is that it is naturally limiting and verbose when it comes to varying vector widths. &nbsp;Is it good to have int2,int4,int8,int16... ad nauseum? Perhaps it is, but it may be worth considering defining a
 type with more generic semantics as well to allow the writing of code to "native SIMD width" rather than specific widths, especially given the proliferation of available widths in newer processors/accelerators.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">—<br>
Sent from <a href="https://www.dropbox.com/mailbox">Mailbox</a> for iPad<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
<div>
<p>On Mon, Jun 3, 2013 at 3:46 PM, Mattson, Timothy G &lt;<a href="mailto:timothy.g.mattson@intel.com" target="_blank">timothy.g.mattson@intel.com</a>&gt; wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Bill,<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The only reference I have to point you to is the OpenCL spec.<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a href="http://www.khronos.org/registry/cl/specs/opencl-1.2.pdf">http://www.khronos.org/registry/cl/specs/opencl-1.2.pdf</a><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Look at section 6.1 and 6.4.<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">--Tim<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href="mailto:cplex-bounces@open-std.org">cplex-bounces@open-std.org</a>
 [mailto:cplex-bounces@open-std.org] <b>On Behalf Of </b>Bill Carlson<br>
<b>Sent:</b> Monday, June 03, 2013 11:14 AM<br>
<b>To:</b> Jeff Hammond<br>
<b>Cc:</b> Al Grant; <a href="mailto:cplex@open-std.org">cplex@open-std.org</a><br>
<b>Subject:</b> Re: [Cplex] Short SIMD vector types<o:p></o:p></span></p>
<p>&nbsp;<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">Hi All,<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I've long thought that C type system extensions are the way to go for many parallel data issues.&nbsp; In UPC they are at the core.&nbsp; In this case it seems like a natural.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
In my mind, the key issue is how generic you want to be.&nbsp; Do you want to support a few specific vector lengths as discrete types or generic? &nbsp; How do you use a C initializer?&nbsp; Is there a "vector mask" concept? All C types supported?&nbsp; etc, etc, etc...&nbsp; A long
 time ago I worked on a couple of (never very released) languages which tried to address vectors as a part of the type system with varying success.&nbsp; Would be fun to think about this again!<br>
<br>
Tim: is there a convenient reference for the OpenCL notation which would be appropriate to look at on this topic?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">Bill Carlson<o:p></o:p></p>
</div>
<p>&nbsp;<o:p></o:p></p>
</div>
<div>
<p>&nbsp;<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mon, Jun 3, 2013 at 12:42 PM, Jeff Hammond &lt;<a href="mailto:jhammond@alcf.anl.gov" target="_blank">jhammond@alcf.anl.gov</a>&gt; wrote:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Robert,<br>
<br>
Well, I generally oppose overkill solutions when designing scientific<br>
codes. &nbsp;Using Open 4.0 to get SIMD support in an otherwise OpenMP-free<br>
code seems like killing ants with a bazooka.<br>
<br>
On a practical level, I find that OpenMP causes me major problems in<br>
at least two contexts:<br>
(1) interoperability with Pthreads (or TBB or Cilk or any other<br>
threading model) is not well-defined - this is openly acknowledged by<br>
the OpenMP community - and one can only hope that the<br>
implementation-defined behavior is going to work in a particular<br>
usage,<br>
(2) when activating the OpenMP passes in the compiler causes<br>
catastrophic side effects.<br>
Both of these have been catastrophic to my productivity on Blue Gene/Q<br>
and I only have a full resolution of (1) so far, so I am not willing<br>
to be dependent on OpenMP for SIMD.<br>
<br>
As a side note, Intel's compiler solution using pragmas that are not<br>
dependent on OpenMP work great for me, but I'd prefer to have SIMD as<br>
a C language feature than a compiler-specific pragma.<br>
<br>
Best,<br>
<br>
Jeff<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
On Mon, Jun 3, 2013 at 9:45 AM, Geva, Robert &lt;<a href="mailto:robert.geva@intel.com">robert.geva@intel.com</a>&gt; wrote:<br>
&gt; Hi Jeff, can you please explain your issue with OpenMP SIMD? Does this extension of OpenMP not work with Pthreads, or does it appear to require you to use the OpenMP run time even if you only use the SIMD portion of OpenMP?<br>
&gt;<br>
&gt; To the extent that the C proposal uses the same ideas from OpenMP SIMD, with keywords instead of #pragmas, I expect that you would be able to use the vector portion of the language without having to also use a task scheduler that you are not interested in.<br>
&gt;<br>
&gt; Robert.<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:cplex-bounces@open-std.org">cplex-bounces@open-std.org</a> [mailto:<a href="mailto:cplex-bounces@open-std.org">cplex-bounces@open-std.org</a>] On Behalf Of Jeff Hammond<br>
&gt; Sent: Monday, June 03, 2013 7:37 AM<br>
&gt; To: Al Grant<br>
&gt; Cc: <a href="mailto:cplex@open-std.org">cplex@open-std.org</a><br>
&gt; Subject: Re: [Cplex] Short SIMD vector types<br>
&gt;<br>
&gt; This would be tremendously useful to have in C. &nbsp;I'm really tired of having to spin a one-off implementation of vectorized code for every FPU ISA out there nor do I want to be dependent on the OpenMP SIMD extensions since I primarily use Pthreads.<br>
&gt;<br>
&gt; IBM has defined vector types for Blue Gene systems in C++ (I can't remember if they work strictly as an extension to C or not since it really doesn't matter); I can share the details if people are interested in looking at that. &nbsp;I suppose someone from IBM
 Toronto is on this list and can elaborate on the design details.<br>
&gt;<br>
&gt; Best,<br>
&gt;<br>
&gt; Jeff<br>
&gt;<br>
&gt; On Mon, Jun 3, 2013 at 6:46 AM, Al Grant &lt;<a href="mailto:Al.Grant@arm.com">Al.Grant@arm.com</a>&gt; wrote:<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; Are short SIMD vector types something that CPLEX is interested in standardizing?<br>
&gt;&gt;<br>
&gt;&gt; Many C implementations already provide these as non-standard<br>
&gt;&gt; predefined types (called e.g. "int16x4_t") and/or by means of<br>
&gt;&gt; constructing short vectors out of existing types (like GCC's "vector"<br>
&gt;&gt; attribute). &nbsp;The intuition is they map on to registers of media instruction sets like SSE, AltiVec, NEON etc.<br>
&gt;&gt;<br>
&gt;&gt; They are standard in OpenCL, although they are not how OpenCL provides<br>
&gt;&gt; large-scale parallelism. &nbsp;But they might be relevant to large-scale<br>
&gt;&gt; parallelism in that the vector type construction could be extended to<br>
&gt;&gt; construct large vectors that could be handled in whatever size chunks fit the target architecture.<br>
&gt;&gt;<br>
&gt;&gt; If there's an existing proposal on this I'd be grateful for a pointer to it.<br>
&gt;&gt;<br>
&gt;&gt; Thanks<br>
&gt;&gt;<br>
&gt;&gt; Al Grant<br>
&gt;&gt;<br>
&gt;&gt; -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for
 any purpose, or store or copy the information in any medium. &nbsp;Thank you.<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Cplex mailing list<br>
&gt;&gt; <a href="mailto:Cplex@open-std.org">Cplex@open-std.org</a><br>
&gt;&gt; <a href="http://www.open-std.org/mailman/listinfo/cplex" target="_blank">http://www.open-std.org/mailman/listinfo/cplex</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Jeff Hammond<br>
&gt; Argonne Leadership Computing Facility<br>
&gt; University of Chicago Computation Institute <a href="mailto:jhammond@alcf.anl.gov">
jhammond@alcf.anl.gov</a> / <a href="tel:%28630%29%20252-5381">(630) 252-5381</a>
<a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
&gt; <a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
&gt; ALCF docs: <a href="http://www.alcf.anl.gov/user-guides" target="_blank">http://www.alcf.anl.gov/user-guides</a><br>
&gt; _______________________________________________<br>
&gt; Cplex mailing list<br>
&gt; <a href="mailto:Cplex@open-std.org">Cplex@open-std.org</a><br>
&gt; <a href="http://www.open-std.org/mailman/listinfo/cplex" target="_blank">http://www.open-std.org/mailman/listinfo/cplex</a><br>
<br>
<br>
<br>
--<br>
Jeff Hammond<br>
Argonne Leadership Computing Facility<br>
University of Chicago Computation Institute<br>
<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / <a href="tel:%28630%29%20252-5381">
(630) 252-5381</a><br>
<a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
<a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
ALCF docs: <a href="http://www.alcf.anl.gov/user-guides" target="_blank">http://www.alcf.anl.gov/user-guides</a><br>
_______________________________________________<br>
Cplex mailing list<br>
<a href="mailto:Cplex@open-std.org">Cplex@open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/cplex" target="_blank">http://www.open-std.org/mailman/listinfo/cplex</a><o:p></o:p></p>
</div>
</div>
</div>
<p>&nbsp;<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
<br>
<font face="Arial" color="Black" size="2">-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents
 to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.<br>
</font>


</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Cplex mailing list</span><br><span><a href="mailto:Cplex@open-std.org">Cplex@open-std.org</a></span><br><span><a href="http://www.open-std.org/mailman/listinfo/cplex">http://www.open-std.org/mailman/listinfo/cplex</a></span><br></div></blockquote></body></html>