[Cplex] Short SIMD vector types

Mattson, Timothy G timothy.g.mattson at intel.com
Mon Jun 3 16:52:00 CEST 2013

I agree that short SIMD vector types would be useful.  I frequently find it easier to code with vector intrinsics then to figure out how to get a compiler to vectorize my code.    Less black magic and more engineering.

Having a portable notation for these short vector operations would be handy.  We have them in OpenCL, but given the way work is decomposed for execution on a GPU, I'm not sure how useful they are.  But we have gone to great effort to define an extension to C that handles short vector types.

It would be interesting to discuss these as a group and get a broader set of eyeballs to look over what we've done in the OpenCL world.   If we decide to add this functionality to C/C++ and if the OpenCL notation is a reasonable solution to the problem, it would be nice to adopt it.   The less fragmentation in the programming language space, the better.


-----Original Message-----
From: 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
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.



On Mon, Jun 3, 2013 at 6:46 AM, Al Grant <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
> http://www.open-std.org/mailman/listinfo/cplex

Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute jhammond at alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond
ALCF docs: http://www.alcf.anl.gov/user-guides
Cplex mailing list
Cplex at open-std.org

More information about the Cplex mailing list