[Cplex] Short SIMD vector types
robert.geva at intel.com
Mon Jun 3 16:45:32 CEST 2013
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.
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:
> 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.
> 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
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