[Openmcl-devel] Using vecLib framework from OpenMCL?

[Gary Byers]

On Tue, 29 Aug 2006, Phil wrote:

> On Aug 29, 2006, at 3:21 AM, Gary Byers wrote:
>
> Thanks for the excellent discussion on the various considerations re:
> SIMD.  The memory alignment discussion will help me with what I'm
> thinking about trying (SIMD via FFI)...
>

There'd be a fair amount of work involved (in the compiler and/or
the function CCL:%FF-CALL and in the asssembly-language glue that
actually does foreign-function calls) in persuading interested
parties to pass SIMD arguments and return SIMD results in vector 
registers.

I think that there's also a fair amount of work involved in deciding
how vector operands are represented as lisp objects.  On 64-bit
platforms, it's practical to consider using lisp vectors or something
like them (subject to some constraints); on 32-bit platforms, that
isn't really practical because of alignment issues.

>> I was never able to come up with an even vaguely lisp-like way of
>> integrating SIMD stuff with a 32-bit lisp; whenever the issue arose,
>> I generally suggested that it'd be better to wait for 64-bit ports
>> because of the alignment issues.  I'm not sure what the priority on
>> this should be,  but I do recognize that I no longer have that excuse.
>
> It almost sounds like the question is *should* OpenMCL bother
> providing native SIMD instruction support?  It doesn't seem like it
> would ever generate truly optimal code with so many unknowns at
> compile time without some pretty ugly, non-standard hinting to the
> compiler.  To get the bang from SIMD, wouldn't substantial chunks of
> non-compiler library code (map comes to mind) and data structures
> have to be altered?  Has going the route Apple is pushing make SIMD a
> library issue and provide an optimized method for passing/retrieving
> data (i.e. SIMD-optimized vectors) and use FFI to call the optimized
> routines been considered (and rejected)?  It seems to provide
> relatively cheap support of SIMD across all architectures for the
> cost of FFI interfaces and a specialized data type.

At least some of the stuff provided by libraries like vecLib are
C compiler intrinsics; vector types are primitive C types in the
same sense that 'int' and 'float' are, and if you "call" vaddf()
in a C program you're really expecting the C compiler to emit
an inline "vector-add-floats" instruction with the right operands
and result.

The next interesting step (which recent versions of GCC have
attempted) is vectorization: if a program has a few floating-point
adds (for instance) that could take place in parallel, the compiler
could pack the operands into vector registers and replace a few
'floating-point-add" instructions with a single
"vector-floating-point-add" instruction; even if you factor in the
cost of packing the operands and unpacking the results whenever that's
necessary, the vector operations are often going to execute faster.
(One drawback is that it may - depending on hardware details - be
more awkward to detect things like overflow/underflow on vector
operations than it is on scalar ones.)

That (vectorization) is hard, but one advantage is that it doesn't
have to be exposed to the user: if the compiler chooses to replace
a few sequential operations with a single parallel one, no one
needs to know or care as long as the result is correct.

Note also that OpenMCL has provided a little bit of support for
doing AltiVec programming in LAP (that mostly consists of
some macros to stack-allocate aligned pointers and that sort of
thing.)  As far as I know, what's there works, but I think that
anyone who's ever tried to do anything with it has been frustrated
by the fact that it's hard to integrate with the rest of the
lisp world.

> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>