[Cplex] Short SIMD vector types

Bill Carlson wwc559 at gmail.com
Mon Jun 3 20:14:13 CEST 2013


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> 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>
> 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] 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
> 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
> > 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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/cplex/attachments/20130603/297f1335/attachment-0001.html 


More information about the Cplex mailing list