3 ms·

I am not convinced that advancing over two different string buffers and comparing their contents - even with a variable amount of advance due to character encod

I am not convinced that advancing over two different string buffers and comparing their contents - even with a variable amount of advance due to character encoding - would have a branch miss in it if programmed by a competent programmer in any language. I am also not convinced that this problem can't be completely clobbered by SIMD, regardless of platform (x86 vs Neon) and language (Haskell, C, whatever). A comparison of languages in this case for performance (outside the kiddy division) would either (a) center around which language could get the hell out of the way and let the programmer use intrinsics or (b) which language could actually allow the programmer to express SIMD concepts in a nice language-friendly way. I have occasionally seen some pretty cool stuff from FP folks in the latter direction, which, if brought to production quality, would allow FP people to absolutely slaughter naive C code.

tathougies 8y ago
There is a summer of code project this year to make GHC output SIMD code from standard Haskell code. The llvm backend does this now, but it comes at the cost of being less efficient on normal Haskell code, and also unable to access all the rich type information that GHC theoretically could. Nevertheless, GHC has all SIMD intrinsics available for use, and they're all type checked, as you'd expect: https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#g:29 https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GH...
kccqzy 8y ago
> I have occasionally seen some pretty cool stuff from FP folks in the latter direction, which, if brought to production quality, would allow FP people to absolutely slaughter naive C code. I'd love to hear more stories about this! Any links? So far my own approach is to use Haskell as basically a glorified DSL for LLVM IR and bypass Haskell codegen altogether. From there either JIT it or AOT it into native code.

tathougies 8y ago

There is a summer of code project this year to make GHC output SIMD code from standard Haskell code. The llvm backend does this now, but it comes at the cost of being less efficient on normal Haskell code, and also unable to access all the rich type information that GHC theoretically could. Nevertheless, GHC has all SIMD intrinsics available for use, and they're all type checked, as you'd expect: https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#g:29 https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GH...

kccqzy 8y ago

> I have occasionally seen some pretty cool stuff from FP folks in the latter direction, which, if brought to production quality, would allow FP people to absolutely slaughter naive C code. I'd love to hear more stories about this! Any links? So far my own approach is to use Haskell as basically a glorified DSL for LLVM IR and bypass Haskell codegen altogether. From there either JIT it or AOT it into native code.