Matthew Roberts wrote:

Does anybody know if any of the Haskell compilers are able to optimise for vector units (like MMX, SSE(2), 3D_Now! and AltiVec)?

No, not as yet. FP systems don't generally provide enough control over how data is laid out in memory to be able to invoke SIMD operations on it (or control data locality). I suppose you could add an unboxed Float32x4 type and appropriate instances of IOArrays etc to GHC, but if you wanted to do anything with it you'd have to use specialised unboxed operations.. and it'd probably be more trouble than just writing it in assembler. I would have thought that if a developer cared enough about the performance of their program to turn to non-portable SIMD extensions, they'd want to write it in assembler anyway so they had absolute control over what was going on.. ... though it would be nice to be able to define a + b :: (Float, Float, Float, Float) -> (Float, Float, Float, Float) -> (Float, Float, Float, Float) and expect it to go via SSE.. Ben.

My investigations have revealed that c requires special programming constructs to make the most of these processor capabilites (i.e. the compiler is not able to work it out for itself).

Is there any work on getting haskell compilers to work this kind of thing out?

Cheers,

Matt