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.
The following blog post goes into the reasons, and the remedies. In particular, there are ways to automatically devectorise your code.
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)). It would be great to have a language where for loops and vector expressions are fast.
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.
http://ghc.haskell.org/trac/ghc/ticket/915
It's still one of the most impressive moves to a sufficiently smart compiler.
The different fusion strategies have different trade offs, so it could also be that I'm not reading your with the correct nuance.
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.