4 ms·

I thought F# and Haskell were at least on the same level of performance, if not faster. Is it not the case?

ldrndll 11y ago
Anecdotally, OCaml seems to often be faster than Haskell, though not necessarily materially so. More important though (in my opinion at least) is that it seems performance is more predictable in OCaml. High performance code in Haskell tends to rely on a combination of stream fusion, rewrite rules firing and judicious use of unboxing and bang patterns. I've heard it said that the OCaml compilers simplicity makes it far easier to know what code it's going to produce. Disclaimer: I'm a Haskell user, so it might just be that I'm more familiar with Haskell's warts.
- tel 11y ago
  It's worth noting as well that the flambda branch of the OCaml compiler is starting to include lots of these advanced optimizations which will (a) probably improve performance, (b) make abstraction more "free" enabling more use of it, and (c) put a hit on performance predictability again.
jlouis 11y ago
These questions often depend on how much time you are willing to spend making things fast. OCaml has an extremely predictable performance curve, which is nice when you are writing code that has to run fast. In turn, productivity is good because you don't get into situations where you have to rewrite code to make it faster in many cases. Even for brute-force algorithms, it tend to run fast enough that it would work well. Over F#, OCaml provides a module system. This helps programming in the very large. Over Haskell, OCaml provides a module system, and strict evaluation. The latter is a contended point, but proponents of OCaml claim it leads to memory/execution predictability. In Haskell (GHC) you often have to turn on optimizations in order to understand how your code will perform in reality, whereas byte-code interpreted OCaml acts just like natively compiled OCaml space wise, but is roughly 10 times faster in execution speed.
- ics 11y ago
  Hey but GHC just got -XStrict! https://github.com/ghc/ghc/commit/46a03fbec6a02761db079d1746532565f34c340f https://github.com/ghc/ghc/commit/46a03fbec6a02761db079d1746...
  - TuringTest 11y ago
    But will idiomatic Haskell work with that option turned on? Genuine question. Wouldn't it change the require programming style to make use of the strict setting?
    - ics 11y ago
      Currently you can deal with strictness using Bang Patterns. The addition of Strict and StrictData with -XStrict simply lets module writers cut down on that noise and communicates intent. It isn't meant to change or split the language Haskell in two; except for testing, you probably wouldn't go enabling it everywhere just 'cause. More info on strictness and Bang Patterns: https://wiki.haskell.org/Performance/Strictness#Explicit_strictness https://wiki.haskell.org/Performance/Strictness#Explicit_str... This was posted to r/haskell today and helps explain things a bit: http://blog.johantibell.com/2015/11/the-design-of-strict-haskell-pragma.html http://blog.johantibell.com/2015/11/the-design-of-strict-has...
- thesz 11y ago
  Strict evaluation order is less composable. It is less expressive, actually.
iamsohungry 11y ago
Not trivially, no. Naive implementations in Haskell/F# are almost universally slower than naive implementations of the same algorithm in OCaml. In Haskell, this is partly due to lazy evaluation (which many production Haskell projects turn off) and in F# it's largely due to the baggage of interacting with the CLR (I have less knowledge about this, I'll admit). I think it only makes sense to talk about naive, idiomatic implementations of an algorithm when you're talking about the performance of a language. If you start talking about highly optimized versions of algorithms, it's harder to make statements about which language is faster. People who use numpy adeptly get extraordinary performance in Python, but I don't think that makes the argument that Python is faster than OCaml; it's hard to say what an equivalent level of optimization in OCaml would look like.

Anecdotally, OCaml seems to often be faster than Haskell, though not necessarily materially so. More important though (in my opinion at least) is that it seems performance is more predictable in OCaml. High performance code in Haskell tends to rely on a combination of stream fusion, rewrite rules firing and judicious use of unboxing and bang patterns. I've heard it said that the OCaml compilers simplicity makes it far easier to know what code it's going to produce. Disclaimer: I'm a Haskell user, so it might just be that I'm more familiar with Haskell's warts.

tel 11y ago
It's worth noting as well that the flambda branch of the OCaml compiler is starting to include lots of these advanced optimizations which will (a) probably improve performance, (b) make abstraction more "free" enabling more use of it, and (c) put a hit on performance predictability again.

jlouis 11y ago

These questions often depend on how much time you are willing to spend making things fast. OCaml has an extremely predictable performance curve, which is nice when you are writing code that has to run fast. In turn, productivity is good because you don't get into situations where you have to rewrite code to make it faster in many cases. Even for brute-force algorithms, it tend to run fast enough that it would work well. Over F#, OCaml provides a module system. This helps programming in the very large. Over Haskell, OCaml provides a module system, and strict evaluation. The latter is a contended point, but proponents of OCaml claim it leads to memory/execution predictability. In Haskell (GHC) you often have to turn on optimizations in order to understand how your code will perform in reality, whereas byte-code interpreted OCaml acts just like natively compiled OCaml space wise, but is roughly 10 times faster in execution speed.

ics 11y ago
Hey but GHC just got -XStrict! https://github.com/ghc/ghc/commit/46a03fbec6a02761db079d1746532565f34c340f https://github.com/ghc/ghc/commit/46a03fbec6a02761db079d1746...
- TuringTest 11y ago
  But will idiomatic Haskell work with that option turned on? Genuine question. Wouldn't it change the require programming style to make use of the strict setting?
  - ics 11y ago
    Currently you can deal with strictness using Bang Patterns. The addition of Strict and StrictData with -XStrict simply lets module writers cut down on that noise and communicates intent. It isn't meant to change or split the language Haskell in two; except for testing, you probably wouldn't go enabling it everywhere just 'cause. More info on strictness and Bang Patterns: https://wiki.haskell.org/Performance/Strictness#Explicit_strictness https://wiki.haskell.org/Performance/Strictness#Explicit_str... This was posted to r/haskell today and helps explain things a bit: http://blog.johantibell.com/2015/11/the-design-of-strict-haskell-pragma.html http://blog.johantibell.com/2015/11/the-design-of-strict-has...
thesz 11y ago
Strict evaluation order is less composable. It is less expressive, actually.

iamsohungry 11y ago

Not trivially, no. Naive implementations in Haskell/F# are almost universally slower than naive implementations of the same algorithm in OCaml. In Haskell, this is partly due to lazy evaluation (which many production Haskell projects turn off) and in F# it's largely due to the baggage of interacting with the CLR (I have less knowledge about this, I'll admit). I think it only makes sense to talk about naive, idiomatic implementations of an algorithm when you're talking about the performance of a language. If you start talking about highly optimized versions of algorithms, it's harder to make statements about which language is faster. People who use numpy adeptly get extraordinary performance in Python, but I don't think that makes the argument that Python is faster than OCaml; it's hard to say what an equivalent level of optimization in OCaml would look like.