4 ms·

Comparing it against Rust doesn't really seem fair. If I wasn't using Haskell, I'd be writing Erlang, and last I checked GHC is much faster than Erlang/OTP. Cer

Comparing it against Rust doesn't really seem fair. If I wasn't using Haskell, I'd be writing Erlang, and last I checked GHC is much faster than Erlang/OTP. Certainly faster than CPython, Ruby, and most Node.js. Trying to compete with Rust or C++ performance in Haskell is certainly frustrating to reason about :)

pletnes 9y ago
While "GHC is faster than CPython" is a fairly accurate generalization, I still think python performance is easier to reason about. Haskell can give you fast code, but sometimes it will be super slow for no obvious reason.
- motet_a 9y ago
  Moreover, CPython is a interpreter without JIT while GHC compiles to machine code. This is totally different. IMHO, it is much more correct to compare a JIT-enabled interpreter to GHC.
- chongli 9y ago
  super slow for no obvious reason Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know. GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-nonstrict data structures) so that the profiling tools become a last resort.
  - whatshisface 9y ago
    A sufficiently smart [compiler | developer] can [make it so that | think] anything is easy. Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs that can make a single line worse than O(1).) "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell.
    - cesarb 9y ago
      > "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell. Unless you use GCC's cleanup extension (which runs an arbitrary function when leaving a scope, similar to Rust's Drop trait). Or evil macros which turn innocent-looking code into something else (a well-known project, in some compilation modes, redefines the "if" keyword to track how many times each branch is taken). Or both at the same time (like hiding GCC's cleanup extension with a macro).
    - xwvvvvwx 9y ago
      Since performance is exactly a measure of the number of imperative steps that need to happen in a program This is an oversimplification. Writing fast code for modern processors is all about how much time you spend waiting for memory.
      - saosebastiao 9y ago
        Cache locality will never beat algorithmic complexity as a performance factor. Don't exaggerate its importance.
        falcolas 9y ago
        It can, when the constant portion of the algorithm chosen is high and the number of items being pushed through the algorithm is low. e.g. bubblesort will beat quicksort for tiny lists or large lists which are already sorted. Or, put another way, 1000 operations against 1ns latency memory (L1) has the same performance as 10 operations against 100ns latency memory (RAM).
      - FullyFunctional 9y ago
        This is an oversimplification. Some compute intensive parts can get significant speed ups through careful use of data parallelism (such as SIMD). Others needs parallelism at the thread level. Etc. Optimizing for memory patterns is important as is trying to keep the working set within a near-level cache.
lambdadmitry 9y ago
I would argue that at least for client-server apps Erlang is faster. Here is why: in most cases the perceived performance of a server is constrained by maximum (or 99%, whatever) latency, not by throughput. Moreover, you can scale throughput horizontally, while scaling for latency is more or less impossible. Haskell's GC can give you horrendous pauses (see [1][2]), ruining perceived performance. Erlang, on the other hand, is thoroughly optimized for minimal latency. TL;DR: "fast" isn't well-defined, and for a lot (or even most) applications "fast" is about latency, not throughput, and Erlang is "faster" in that sense. [1] https://making.pusher.com/latency-working-set-ghc-gc-pick-two/ https://making.pusher.com/latency-working-set-ghc-gc-pick-tw... [2] they eventually abandoned Haskell for Go https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/ https://making.pusher.com/golangs-real-time-gc-in-theory-and...
- Tarean 9y ago
  Yeah, the worst case of ghc's garbage collection is awful and can dwarf the actual work being done. That's the man driving factor behind adding linear types to haskell - they let long lived and large data live on a separate non-gced heap. The other big part of this is that it can make stream fusion predictable. Currently haskell programs can become 100x slower or faster after some innocuous change, so linear types will make it a lot easier to write fast haskell in general. http://blog.tweag.io/posts/2017-03-13-linear-types.html http://blog.tweag.io/posts/2017-03-13-linear-types.html
hajile 9y ago
Why not SML/CML where you basically get haskell syntax and types, but get modules, no laziness, and you can mutate things when it's more efficient to do so.
- lmm 9y ago
  I couldn't stand to work without HKT now that I'm used to them. (Hell, I'm struggling with Scala's lack of polykinded types; you don't need them until you do, but then you really need them).
  - adamwk 9y ago
    MLs have higher kinder types.
    - lmm 9y ago
      Which ones? OCaml is planning to add them via its "modular implicits" work but that hasn't happened yet; none of the SML implementations I used mentioned them.
      - adamwk 9y ago
        I think you're confusing higher-kinded types with type classes. You're right that neither has type classes.
- FullyFunctional 9y ago
  The difference in both syntax and type system is vast, unless you are coming from, say Fortran or APL.
dpratt 9y ago
Scala would like to have a word with you.

pletnes 9y ago

While "GHC is faster than CPython" is a fairly accurate generalization, I still think python performance is easier to reason about. Haskell can give you fast code, but sometimes it will be super slow for no obvious reason.

motet_a 9y ago
Moreover, CPython is a interpreter without JIT while GHC compiles to machine code. This is totally different. IMHO, it is much more correct to compare a JIT-enabled interpreter to GHC.
chongli 9y ago
super slow for no obvious reason Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know. GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-nonstrict data structures) so that the profiling tools become a last resort.
- whatshisface 9y ago
  A sufficiently smart [compiler | developer] can [make it so that | think] anything is easy. Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs that can make a single line worse than O(1).) "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell.
  - cesarb 9y ago
    > "Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell. Unless you use GCC's cleanup extension (which runs an arbitrary function when leaving a scope, similar to Rust's Drop trait). Or evil macros which turn innocent-looking code into something else (a well-known project, in some compilation modes, redefines the "if" keyword to track how many times each branch is taken). Or both at the same time (like hiding GCC's cleanup extension with a macro).
  - xwvvvvwx 9y ago
    Since performance is exactly a measure of the number of imperative steps that need to happen in a program This is an oversimplification. Writing fast code for modern processors is all about how much time you spend waiting for memory.
    - saosebastiao 9y ago
      Cache locality will never beat algorithmic complexity as a performance factor. Don't exaggerate its importance.
      - falcolas 9y ago
        It can, when the constant portion of the algorithm chosen is high and the number of items being pushed through the algorithm is low. e.g. bubblesort will beat quicksort for tiny lists or large lists which are already sorted. Or, put another way, 1000 operations against 1ns latency memory (L1) has the same performance as 10 operations against 100ns latency memory (RAM).
    - FullyFunctional 9y ago
      This is an oversimplification. Some compute intensive parts can get significant speed ups through careful use of data parallelism (such as SIMD). Others needs parallelism at the thread level. Etc. Optimizing for memory patterns is important as is trying to keep the working set within a near-level cache.

lambdadmitry 9y ago

I would argue that at least for client-server apps Erlang is faster. Here is why: in most cases the perceived performance of a server is constrained by maximum (or 99%, whatever) latency, not by throughput. Moreover, you can scale throughput horizontally, while scaling for latency is more or less impossible. Haskell's GC can give you horrendous pauses (see [1][2]), ruining perceived performance. Erlang, on the other hand, is thoroughly optimized for minimal latency. TL;DR: "fast" isn't well-defined, and for a lot (or even most) applications "fast" is about latency, not throughput, and Erlang is "faster" in that sense. [1] https://making.pusher.com/latency-working-set-ghc-gc-pick-two/ https://making.pusher.com/latency-working-set-ghc-gc-pick-tw... [2] they eventually abandoned Haskell for Go https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/ https://making.pusher.com/golangs-real-time-gc-in-theory-and...

Tarean 9y ago
Yeah, the worst case of ghc's garbage collection is awful and can dwarf the actual work being done. That's the man driving factor behind adding linear types to haskell - they let long lived and large data live on a separate non-gced heap. The other big part of this is that it can make stream fusion predictable. Currently haskell programs can become 100x slower or faster after some innocuous change, so linear types will make it a lot easier to write fast haskell in general. http://blog.tweag.io/posts/2017-03-13-linear-types.html http://blog.tweag.io/posts/2017-03-13-linear-types.html

hajile 9y ago

Why not SML/CML where you basically get haskell syntax and types, but get modules, no laziness, and you can mutate things when it's more efficient to do so.

lmm 9y ago
I couldn't stand to work without HKT now that I'm used to them. (Hell, I'm struggling with Scala's lack of polykinded types; you don't need them until you do, but then you really need them).
- adamwk 9y ago
  MLs have higher kinder types.
  - lmm 9y ago
    Which ones? OCaml is planning to add them via its "modular implicits" work but that hasn't happened yet; none of the SML implementations I used mentioned them.
    - adamwk 9y ago
      I think you're confusing higher-kinded types with type classes. You're right that neither has type classes.
FullyFunctional 9y ago
The difference in both syntax and type system is vast, unless you are coming from, say Fortran or APL.

dpratt 9y ago

Scala would like to have a word with you.