What's really more performant? Haskell or OCam

问题:

I spent the last 18 months getting the grip of functional programming, starting with learning OCaml and for some weeks now Haskell. Now I want to take the next step and implement some actual application: A simple realtime terrain editor. I've written numerous realtime terrain rendering engines, so this is a familiar topic. And the used recursive algorithms and data structures seem very fit for a functional implementation.

With this being a realtime application I'm naturally looking for the best performance I can get. Now some (IMHO quite annoying) proponent of OCaml quite frequently bitches against Haskell being slow compared to OCaml or F#. But according to the The Computer Language Benchmarks Game Haskell oftenly beats OCaml, if only by rather small fractions — there remains the problem, that this benchmark takes only very specific samples.

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

But maybe other people did comparable applications in OCaml and Haskell and give some figures?

回答1:

By all accounts, both OCaml and Haskell have sufficiently performant compilers and runtimes for almost anything. Picking between them on the basis of pure performance seems silly to me. You've come this far -- moving away from the obviously most low-level and performant languages (C, C++, etc.) in the name of clearer, more succinct, more expressive, higher-level code. So why, when the performance differences involved are much smaller, switch to that criteria now?

I'd go with some broader criteria -- if you want pervasive parallelism, then Haskell's the better choice. If you want genuinely pervasive mutation, then OCaml is better.

If you want only very coarse parallelism at best, and you intend to stick with mostly functional structures, then pick based on something else, like syntax (I think Haskell is much nicer here, but that's subjective) or available libraries (Haskell wins on quantity/availability, but OCaml might edge it out in the graphics department nonetheless).

I don't think you'll go wrong either way

回答2:

With help from two very smart colleagues, I've written a dataflow-optimization library in both Objective Caml and Haskell. The Haskell version is a bit more polymorphic, has more compile-time type checking, and therefore has less run-time checking. The OCaml version uses mutable state to accumulate dataflow facts, which might 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 are not worth fooling with. That is, in the respective compilers (Quick C-- and GHC), so little time is spent in dataflow optimization that the code is not worth improving.

Benchmarking is hell.

回答3:

I've written numerous realtime terrain rendering engines, so this is a familiar topic.

Familiar enough to know where most time will be spent?

If so then maybe you can write code for just that part in different languages and compare.

But according to the The Computer Language Benchmarks Game Haskell often beats OCaml, if only by rather small fractions — there remains the problem, that this benchmark takes only very specific samples.

The benchmarks game reports 4 sets of results - one core and quad core, 32 or 64 bit Ubuntu - and you may find that the OCaml or Haskell benchmark programs perform better or worse depending on the platform.

All a benchmark can do is take very specific samples, and of course you should disregard comparisons on tasks that are unlike where most time will be spent in your application - large integer arithmetic? regex? strings? - and look at the comparisons that are most like what you intend to do.

回答4:

Based on all the data I've seen, they are roughly comparable. The code you write will make a bigger difference than the language itself.

回答5:

Interesting question. This whole-planet terrain renderer was one of the last programs I wrote in C++ before I migrated to OCaml. Looking back, that program would have been vastly easier to write in OCaml than C++. Haskell should make it comparably-easy but programs are usually much harder to optimize in Haskell. In theory, Haskell has better support for multicores but, in practice, even experts rarely get decent results using Haskell for parallel programming.

Also, for real-time applications you will also want low pause times from the garbage collector. OCaml has a nice incremental collector that results in few pauses above 30ms but, IIRC, GHC has a stop-the-world collector that incurs arbitrarily-long pauses.

I assume you're using Linux or F# would be a much better choice than either OCaml or Haskell.

EDIT: If you want to study the shootout then make sure you read the source code. You may also find the Haskell wiki pages about it interesting.