6 ms·

I'm not sure how your Maybe type representation would help with the OP's concern about SIMD optimization. It's a theoretically clean approach, but this article

by rcoder 12y ago

I'm not sure how your Maybe type representation would help with the OP's concern about SIMD optimization. It's a theoretically clean approach, but this article is largely focused on how to keep the (SIMD-aware) compiler humming along on large vectors without reverting to scalar operations. AFAICT GHC only has experimental support for SIMD optimizations anyway, so this is probably less of an issue for Haskell code than it is for C/C++/Fortan numeric primitives (and languages like Julia which utilize them).

carterschonwald 12y ago
I can totally get struct of arrays format in haskell (Heck, the Unboxed.* modules in the vector package are basically that http://hackage.haskell.org/package/vector http://hackage.haskell.org/package/vector) I can define the SOA format as something like (Vector Bool, Vector Bool, Vector a, Vector b), or something similarly along those lines. That allows a pretty reasonable branchless vectorized formulation with only a relatively small ~2x space overhead for most pointwise operations. I actually wrote a prototype of a simd backed vectorized arithmetic lib for haskell that does the right thing over a year ago, https://github.com/wellposed/vector-vectorized https://github.com/wellposed/vector-vectorized, but the fact of the matter is that pointwise simd is honestly kinda boring, it really only is useful for streaming/linear time workloads. What more interesting is SIMD on super linear time algorithms like FFT and (Dense) Matrix multiply, along with on compressed structures and audio/video. In all of these latter cases, SIMD shuffle matters to! And I've not yet seen a high level language that does a good treatment of supporting simd shuffles. https://github.com/flame/blis/blob/master/kernels/x86_64/avx/3/bli_gemm_asm_d8x4.c https://github.com/flame/blis/blob/master/kernels/x86_64/avx... is a very very good example of how shuffle/permutation heavy interesting SIMD gets. (The associated project, BLIS, is a modern, amazingly well engineered sequel to blas, written in C, thats easy to customize to new architectures). I definitely agree that GHC's current SIMD isnt very useful, it lacks nice support for shuffles, and its a bit weird (it naively just bundles up the LLVM simd api). I hope to work with a few folks to fix that up in time for GHC 7.12, I actually spent a bit of time this summer trying to plan out some design ideas.

by rcoder 12y ago

carterschonwald 12y ago

I can totally get struct of arrays format in haskell (Heck, the Unboxed.* modules in the vector package are basically that http://hackage.haskell.org/package/vector http://hackage.haskell.org/package/vector) I can define the SOA format as something like (Vector Bool, Vector Bool, Vector a, Vector b), or something similarly along those lines. That allows a pretty reasonable branchless vectorized formulation with only a relatively small ~2x space overhead for most pointwise operations. I actually wrote a prototype of a simd backed vectorized arithmetic lib for haskell that does the right thing over a year ago, https://github.com/wellposed/vector-vectorized https://github.com/wellposed/vector-vectorized, but the fact of the matter is that pointwise simd is honestly kinda boring, it really only is useful for streaming/linear time workloads. What more interesting is SIMD on super linear time algorithms like FFT and (Dense) Matrix multiply, along with on compressed structures and audio/video. In all of these latter cases, SIMD shuffle matters to! And I've not yet seen a high level language that does a good treatment of supporting simd shuffles. https://github.com/flame/blis/blob/master/kernels/x86_64/avx/3/bli_gemm_asm_d8x4.c https://github.com/flame/blis/blob/master/kernels/x86_64/avx... is a very very good example of how shuffle/permutation heavy interesting SIMD gets. (The associated project, BLIS, is a modern, amazingly well engineered sequel to blas, written in C, thats easy to customize to new architectures). I definitely agree that GHC's current SIMD isnt very useful, it lacks nice support for shuffles, and its a bit weird (it naively just bundles up the LLVM simd api). I hope to work with a few folks to fix that up in time for GHC 7.12, I actually spent a bit of time this summer trying to plan out some design ideas.