[Cplex] Short SIMD vector types

Olivier Giroux OGiroux at nvidia.com
Tue Jun 4 16:17:33 CEST 2013


One comment inline...

Olivier

On Jun 4, 2013, at 1:56 AM, "Al Grant" <Al.Grant at arm.com<mailto:Al.Grant at arm.com>> wrote:

Hi,

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.  We see this a lot in graphics / game physics.  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).  Usually we have 3 or 4 elements (sometimes 2).  Data type would often be float32 (I guess float64, increasingly),

[olivier] No, it's going the other way: fp16, increasingly.  There is effectively zero fp64 in graphics and game physics.

sometimes int32 or int16, which may be interpreted as Q31 or Q15.

The programmer’s understanding of what the lanes mean, and the appropriate names for the lanes, is dependent on the application.  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.

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).  Some of those might be standard, some third-party.  If the short vectors are provided as generic types (int4 / int32x4_t etc.) then that’s the obvious argument type for vectors.  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.

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.

Al



From: Tom Scogland [mailto:tom.scogland at gmail.com]
Sent: 03 June 2013 23:31
To: Timothy G Mattson
Cc: Jeff Hammond; cplex at open-std.org<mailto:cplex at open-std.org>; Bill Carlson; Al Grant
Subject: Re: [Cplex] Short SIMD vector types

Both OpenCL, as mentioned, and CUDA provide similarly natural short vectors through types for specific widths.  They are far easier to manage than traditional vector intrinsics, especially for those new to SIMD programming.

A big issue with that approach though is that it is naturally limiting and verbose when it comes to varying vector widths.  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.
—
Sent from Mailbox<https://www.dropbox.com/mailbox> for iPad


On Mon, Jun 3, 2013 at 3:46 PM, Mattson, Timothy G <timothy.g.mattson at intel.com<mailto:timothy.g.mattson at intel.com>> wrote:
Bill,


The only reference I have to point you to is the OpenCL spec.


http://www.khronos.org/registry/cl/specs/opencl-1.2.pdf


Look at section 6.1 and 6.4.


--Tim






From: cplex-bounces at open-std.org<mailto:cplex-bounces at open-std.org> [mailto:cplex-bounces at open-std.org] On Behalf Of Bill Carlson
Sent: Monday, June 03, 2013 11:14 AM
To: Jeff Hammond
Cc: Al Grant; cplex at open-std.org<mailto:cplex at open-std.org>
Subject: Re: [Cplex] Short SIMD vector types


Hi All,
I've long thought that C type system extensions are the way to go for many parallel data issues.  In UPC they are at the core.  In this case it seems like a natural.

In my mind, the key issue is how generic you want to be.  Do you want to support a few specific vector lengths as discrete types or generic?   How do you use a C initializer?  Is there a "vector mask" concept? All C types supported?  etc, etc, etc...  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.  Would be fun to think about this again!

Tim: is there a convenient reference for the OpenCL notation which would be appropriate to look at on this topic?
Cheers,
Bill Carlson




On Mon, Jun 3, 2013 at 12:42 PM, Jeff Hammond <jhammond at alcf.anl.gov<mailto:jhammond at alcf.anl.gov>> wrote:
Hi Robert,

Well, I generally oppose overkill solutions when designing scientific
codes.  Using Open 4.0 to get SIMD support in an otherwise OpenMP-free
code seems like killing ants with a bazooka.

On a practical level, I find that OpenMP causes me major problems in
at least two contexts:
(1) interoperability with Pthreads (or TBB or Cilk or any other
threading model) is not well-defined - this is openly acknowledged by
the OpenMP community - and one can only hope that the
implementation-defined behavior is going to work in a particular
usage,
(2) when activating the OpenMP passes in the compiler causes
catastrophic side effects.
Both of these have been catastrophic to my productivity on Blue Gene/Q
and I only have a full resolution of (1) so far, so I am not willing
to be dependent on OpenMP for SIMD.

As a side note, Intel's compiler solution using pragmas that are not
dependent on OpenMP work great for me, but I'd prefer to have SIMD as
a C language feature than a compiler-specific pragma.

Best,

Jeff

On Mon, Jun 3, 2013 at 9:45 AM, Geva, Robert <robert.geva at intel.com<mailto:robert.geva at intel.com>> wrote:
> 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?
>
> 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.
>
> Robert.
>
> -----Original Message-----
> From: cplex-bounces at open-std.org<mailto:cplex-bounces at open-std.org> [mailto:cplex-bounces at open-std.org<mailto:cplex-bounces at open-std.org>] On Behalf Of Jeff Hammond
> Sent: Monday, June 03, 2013 7:37 AM
> To: Al Grant
> Cc: cplex at open-std.org<mailto:cplex at open-std.org>
> Subject: Re: [Cplex] Short SIMD vector types
>
> This would be tremendously useful to have in C.  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.
>
> 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.  I suppose someone from IBM Toronto is on this list and can elaborate on the design details.
>
> Best,
>
> Jeff
>
> On Mon, Jun 3, 2013 at 6:46 AM, Al Grant <Al.Grant at arm.com<mailto:Al.Grant at arm.com>> wrote:
>> Hi,
>>
>> Are short SIMD vector types something that CPLEX is interested in standardizing?
>>
>> Many C implementations already provide these as non-standard
>> predefined types (called e.g. "int16x4_t") and/or by means of
>> constructing short vectors out of existing types (like GCC's "vector"
>> attribute).  The intuition is they map on to registers of media instruction sets like SSE, AltiVec, NEON etc.
>>
>> They are standard in OpenCL, although they are not how OpenCL provides
>> large-scale parallelism.  But they might be relevant to large-scale
>> parallelism in that the vector type construction could be extended to
>> construct large vectors that could be handled in whatever size chunks fit the target architecture.
>>
>> If there's an existing proposal on this I'd be grateful for a pointer to it.
>>
>> Thanks
>>
>> Al Grant
>>
>> -- 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.
>>
>> _______________________________________________
>> Cplex mailing list
>> Cplex at open-std.org<mailto:Cplex at open-std.org>
>> http://www.open-std.org/mailman/listinfo/cplex
>
>
>
> --
> Jeff Hammond
> Argonne Leadership Computing Facility
> University of Chicago Computation Institute jhammond at alcf.anl.gov<mailto:jhammond at alcf.anl.gov> / (630) 252-5381<tel:%28630%29%20252-5381> http://www.linkedin.com/in/jeffhammond
> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
> ALCF docs: http://www.alcf.anl.gov/user-guides
> _______________________________________________
> Cplex mailing list
> Cplex at open-std.org<mailto:Cplex at open-std.org>
> http://www.open-std.org/mailman/listinfo/cplex



--
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov<mailto:jhammond at alcf.anl.gov> / (630) 252-5381<tel:%28630%29%20252-5381>
http://www.linkedin.com/in/jeffhammond
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
ALCF docs: http://www.alcf.anl.gov/user-guides
_______________________________________________
Cplex mailing list
Cplex at open-std.org<mailto:Cplex at open-std.org>
http://www.open-std.org/mailman/listinfo/cplex




-- 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.
_______________________________________________
Cplex mailing list
Cplex at open-std.org<mailto:Cplex at open-std.org>
http://www.open-std.org/mailman/listinfo/cplex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/cplex/attachments/20130604/2e5e4f37/attachment-0001.html 


More information about the Cplex mailing list