[Cplex] Short SIMD vector types
wwc559 at gmail.com
Mon Jun 3 20:14:13 CEST 2013
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
Tim: is there a convenient reference for the OpenCL notation which would be
appropriate to look at on this topic?
On Mon, Jun 3, 2013 at 12:42 PM, Jeff Hammond <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
> (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.
> On Mon, Jun 3, 2013 at 9:45 AM, Geva, Robert <robert.geva at intel.com>
> > 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
> > 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] 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.
> > Best,
> > Jeff
> > 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
> >> 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
> > 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
> > 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
> ALCF docs: http://www.alcf.anl.gov/user-guides
> Cplex mailing list
> Cplex at open-std.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cplex