What is really more productive? Haskell or OCaml

I spent the last 18 months gaining control over functional programming, starting with learning OCaml and for several weeks now Haskell. Now I want to take the next step and implement some real application: a simple real-time landscape editor. I wrote numerous real-time rendering engines, so this is a familiar topic. And the recursive algorithms and data structures used seem very suitable for functional implementation.

If this application is in real time, I'm naturally looking for the best performance I can get. Now, some (IMHO quite annoying) proponents of OCaml quite often poke against Haskell slow compared to OCaml or F #. But according to the Benchmarks Game Haskell Computer Game, it often beats OCaml, if only in fairly small fractions - the problem remains that this test accepts only very specific samples.

The right thing, of course, would be to implement the program in both languages ​​and then compare, but I just don't want to do the double job.

But maybe other people made comparable applications in OCaml and Haskell and gave some numbers?

+50
benchmarking haskell ocaml
Nov 29 '10 at 21:10
source share
5 answers

By all accounts, both OCaml and Haskell have reasonably efficient compilers and runtimes for just about anything. The choice between them on the basis of pure performance seems to me stupid. You have gone so far - moved away from the most obviously low-level and advanced languages ​​(C, C ++, etc.) in the name of a clearer, more concise, more expressive code of a higher level. So why, when the differences in performance are much smaller, go to these criteria now?

I would go with broader criteria - if you want to spread parallelism, then Haskell is the best choice. If you want a truly ubiquitous mutation, then OCaml is better.

If you need only very crude parallelism at best, and you intend to adhere mainly to functional structures, then choose based on something else, such as syntax (I think Haskell is much nicer here, but it's subjective) or the available libraries ( Haskell wins in terms of quantity / availability, but OCaml may refuse this in the graphics department, however).

I do not think that you are mistaken anyway

+57
Nov 30 '10 at 4:38
source share

With the help of two very smart colleagues, I wrote a stream optimization library in Objective Caml and Haskell. The Haskell version is slightly more polymorphic, has more compilation type checking time, and therefore has less runtime verification. The OCaml version uses a volatile state to accumulate data flow facts, which may be faster or slower this week, depending on the phase of the moon. The key fact is that in their intended applications, both libraries are so fast that they should not be fooled with . That is, in the corresponding compilers ( Quick C-- and GHC ), therefore, there is little time in optimizing the data stream, therefore, the code should not be improved.

Benchmarking is hell.

+37
Dec 01 '10 at 3:17
source share

I wrote numerous real-time rendering engines, so this is a familiar topic.

Familiar enough to know where the most time will be spent?

If so, perhaps you can write the code for this part only in different languages ​​and compare.

But in accordance with computer games, the Benchmarks Game Haskell often beats OCaml, even for rather small fractions - the problem remains that this test takes only very specific samples.

The test game presents 4 result sets - one core and a quad core, 32 or 64 bit Ubuntu - and you may find that the OCaml or Haskell Tests work better or worse depending on the platform.

All that the standard can do is take very specific samples, and, of course, you should ignore comparisons on tasks, which, unlike where in your application will be spent most of the time, is large integer arithmetic? regular expression? lines? - and look at the comparisons that are most similar to what you intend to do.

+22
Nov 29 '10 at 22:48
source share

Based on all the data that I saw, they are roughly comparable. The code you write will have more meaning than the language itself.

+19
Nov 29 '10 at 21:15
source share

Interest Ask. This rendering of the landscape of the entire planet was one of the last programs I wrote in C ++ before I switched to OCaml. Looking back, this program would be much easier to write in OCaml than in C ++. Haskell should do this relatively easily, but programs are generally much more difficult to optimize in Haskell. Theoretically, Haskell has better support for multi-core processors, but in practice, even experts rarely get decent results using Haskell for parallel programming.

In addition, for real-time applications, you will also need low pause times from the garbage collector. OCaml has a nice incremental collector that leads to several pauses above 30 ms, but IIRC, GHC has a stop collector that carries arbitrarily long pauses.

I assume that you are using Linux or F # would be a much better choice than OCaml or Haskell.

EDIT: If you want to learn the shootout, make sure you read the source code. You can also find Wask pages in Haskell about this .

+16
Dec 18 '10 at 17:13
source share



All Articles