4 ms·

I'm a little surprised they haven't done loop fusion optimizations like Haskell's "vector". Do they plan to?

carterschonwald 13y ago
I'm not sure what you mean. The Haskell vector library doesn't use any compiler side intelligence. If you mean loop merging, the Repa 4 library does something pretty interesting called series fusion. But it also needs a compiler plugin so that it can do that optimization internally. I'm actually working on my own vectorization / fusion friendly numerical tools in Haskell. One philosophical point that's pretty darn important Is making it obvious and clear how to get good performance in a robust way. Many auto vectorization codes (eg try auto vectorization in clang) require a bit of work to tickle correctly. So in many ways, I think the best approach is to encourage idioms that don't require compiler smarts.
moomin 13y ago
I think you mean stream fusion. While cool, it doesn't actually work in real cases yet. Indeed the ticket to implement it has been closed as invalid because it needs more research. http://ghc.haskell.org/trac/ghc/ticket/915 http://ghc.haskell.org/trac/ghc/ticket/915 It's still one of the most impressive moves to a sufficiently smart compiler.
- carterschonwald 13y ago
  Ummmm. False. No compiler support is needed for Stream fusion. Stream fusion is used in the follow widely used Haskell libraries: Vector, Text, and ByteString. In fact, for any fixed k, I can manufacture natural look Haskell code in these libraries that would be roughly k times slower sans stream fusion. The different fusion strategies have different trade offs, so it could also be that I'm not reading your with the correct nuance.
  - moomin 13y ago
    Don't get me wrong, I'm not criticising what it _can_ do. It's just that the really exciting idea is the SSC idea: where you can just write clean code and have the compiler work out the best execution strategy. At the moment, SF seems to support natural looking code, but not always truly natural code. It's tantalisingly close, but it doesn't seem to be getting any closer.
    - carterschonwald 13y ago
      could you unpack your remarks in a bit more detail?

I'm not sure what you mean. The Haskell vector library doesn't use any compiler side intelligence. If you mean loop merging, the Repa 4 library does something pretty interesting called series fusion. But it also needs a compiler plugin so that it can do that optimization internally. I'm actually working on my own vectorization / fusion friendly numerical tools in Haskell. One philosophical point that's pretty darn important Is making it obvious and clear how to get good performance in a robust way. Many auto vectorization codes (eg try auto vectorization in clang) require a bit of work to tickle correctly. So in many ways, I think the best approach is to encourage idioms that don't require compiler smarts.

moomin 13y ago

I think you mean stream fusion. While cool, it doesn't actually work in real cases yet. Indeed the ticket to implement it has been closed as invalid because it needs more research. http://ghc.haskell.org/trac/ghc/ticket/915 http://ghc.haskell.org/trac/ghc/ticket/915 It's still one of the most impressive moves to a sufficiently smart compiler.

carterschonwald 13y ago
Ummmm. False. No compiler support is needed for Stream fusion. Stream fusion is used in the follow widely used Haskell libraries: Vector, Text, and ByteString. In fact, for any fixed k, I can manufacture natural look Haskell code in these libraries that would be roughly k times slower sans stream fusion. The different fusion strategies have different trade offs, so it could also be that I'm not reading your with the correct nuance.
- moomin 13y ago
  Don't get me wrong, I'm not criticising what it _can_ do. It's just that the really exciting idea is the SSC idea: where you can just write clean code and have the compiler work out the best execution strategy. At the moment, SF seems to support natural looking code, but not always truly natural code. It's tantalisingly close, but it doesn't seem to be getting any closer.
  - carterschonwald 13y ago
    could you unpack your remarks in a bit more detail?