[Cplex] Short SIMD vector types

Tom Scogland tom.scogland at gmail.com
Tue Jun 4 00:30:41 CEST 2013


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 for iPad

On Mon, Jun 3, 2013 at 3:46 PM, Mattson, Timothy G
<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] On Behalf Of Bill Carlson
> Sent: Monday, June 03, 2013 11:14 AM
> To: Jeff Hammond
> Cc: Al Grant; 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/cplex/attachments/20130603/b5b89855/attachment-0001.html 


More information about the Cplex mailing list