26 ms·

That is still the case. The following blog post goes into the reasons, and the remedies. In particular, there are ways to automatically devectorise your code.

by asg 13y ago

That is still the case. The following blog post goes into the reasons, and the remedies. In particular, there are ways to automatically devectorise your code. http://julialang.org/blog/2013/09/fast-numeric/ http://julialang.org/blog/2013/09/fast-numeric/

JulianMorrison 13y ago
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?
blt 13y ago
devectorizing is a terrible step back in expressiveness. It shouldn't be hard to make a compiler that can compute the example without a bunch of temporary arrays. I would be shocked if heavy duty packages like Matlab make all those temporary arrays. On the other hand, I've seen (and written) plenty of code that went through contortions to use vector operations in IDL (http://en.wikipedia.org/wiki/IDL_(programming_language) http://en.wikipedia.org/wiki/IDL_(programming_language)). It would be great to have a language where for loops and vector expressions are fast.
- StefanKarpinski 13y ago
  Matlab does in fact make all those temporary arrays. So does R. See my comment above [1] – the idea is not that you should devectorize everything, but that you can if you need to. Automatic devectorization of general purpose code is not something anyone knows how to do – even in Haskell, which is the best candidate language for such things – see moomin's comment below [2]. [1] https://news.ycombinator.com/item?id=6341406 https://news.ycombinator.com/item?id=6341406 [2] https://news.ycombinator.com/item?id=6341187 https://news.ycombinator.com/item?id=6341187
- ViralBShah 13y ago
  In many cases, our vectorized code is as fast as Matlab or R. In some cases, we need to optimize the way our memory allocation and GC works to reduce the memory pressure created by temporaries. With that, julia should be as good as anything out there on vectorized codes.

by asg 13y ago

JulianMorrison 13y ago

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?

blt 13y ago

devectorizing is a terrible step back in expressiveness. It shouldn't be hard to make a compiler that can compute the example without a bunch of temporary arrays. I would be shocked if heavy duty packages like Matlab make all those temporary arrays. On the other hand, I've seen (and written) plenty of code that went through contortions to use vector operations in IDL (http://en.wikipedia.org/wiki/IDL_(programming_language) http://en.wikipedia.org/wiki/IDL_(programming_language)). It would be great to have a language where for loops and vector expressions are fast.

StefanKarpinski 13y ago
Matlab does in fact make all those temporary arrays. So does R. See my comment above [1] – the idea is not that you should devectorize everything, but that you can if you need to. Automatic devectorization of general purpose code is not something anyone knows how to do – even in Haskell, which is the best candidate language for such things – see moomin's comment below [2]. [1] https://news.ycombinator.com/item?id=6341406 https://news.ycombinator.com/item?id=6341406 [2] https://news.ycombinator.com/item?id=6341187 https://news.ycombinator.com/item?id=6341187
ViralBShah 13y ago
In many cases, our vectorized code is as fast as Matlab or R. In some cases, we need to optimize the way our memory allocation and GC works to reduce the memory pressure created by temporaries. With that, julia should be as good as anything out there on vectorized codes.