3 ms·

In theory, the information a Haskell compiler has available should allow it to make better optimizations. Things like drastic whole-program optimizations aren't

In theory, the information a Haskell compiler has available should allow it to make better optimizations. Things like drastic whole-program optimizations aren't viable in C because the compiler can't guarantee safety and doing the optimizations by hand would render the code base completely unreadable. This is why, for instance, FORTRAN can easily outperform C for certain classes of program. In practice, the overhead of supporting Haskell's other features means it's still generally slower than most popular compiled languages, though not by much. I have much higher expectations, however, for improvement in Haskell optimizers than I do for nontrivial static analysis for impure languages becoming viable.

jrockway 17y ago
Things like drastic whole-program optimizations aren't viable in C Well, LLVM can do this, actually. If you treat C like a programming language instead of portable assembly, you can do interesting things with it.
- dons 17y ago
  It may be infeasible to do all the effect analysis though. You have to reconstruct high level semantics. That's just not going to fly in general, though it will do well in some simple cases.
  - jrockway 17y ago
    I agree. C is weird in that the programmer has to throw away almost all of his intent and just tells the machine exactly what instructions to perform. You can read C and sort of get the idea of what the programmer wanted to do, but it's difficult. In Haskell, there is very little "how" and a lot of "what" (and "why"), and so there is much more opportunity for optimization. Your work with stream fusion is a great example -- what a C programmer might think is a bunch of loops can be condensed down to one loop "sometime later". And in Haskell, these effects can be composed, whereas in C, you are stuck with what the programmer wrote. This is why I am always confused when people say "functional programming is slow" -- current C implementations are very close to being as fast as theoretically possible, where as current FP implementations are nowhere near that (there are many optimization opportunities that are currently unexplored or unimplemented). And even with only a few optimizations, many FP implementations (GHC, OCaml, SBCL) are almost as fast as C already!
DarkShikari 17y ago
This is why, for instance, FORTRAN can easily outperform C for certain classes of program. Not quite. To quote the master: <pengvado> gcc fails to optimize it because gcc has always sucked at arrays <pengvado> that's *the* benefit of fortran The benefit of FORTRAN is due to array and aliasing issues in C, not really whole-program optimization.
- malkia 17y ago
  hence __restrict

jrockway 17y ago

Things like drastic whole-program optimizations aren't viable in C Well, LLVM can do this, actually. If you treat C like a programming language instead of portable assembly, you can do interesting things with it.

dons 17y ago
It may be infeasible to do all the effect analysis though. You have to reconstruct high level semantics. That's just not going to fly in general, though it will do well in some simple cases.
- jrockway 17y ago
  I agree. C is weird in that the programmer has to throw away almost all of his intent and just tells the machine exactly what instructions to perform. You can read C and sort of get the idea of what the programmer wanted to do, but it's difficult. In Haskell, there is very little "how" and a lot of "what" (and "why"), and so there is much more opportunity for optimization. Your work with stream fusion is a great example -- what a C programmer might think is a bunch of loops can be condensed down to one loop "sometime later". And in Haskell, these effects can be composed, whereas in C, you are stuck with what the programmer wrote. This is why I am always confused when people say "functional programming is slow" -- current C implementations are very close to being as fast as theoretically possible, where as current FP implementations are nowhere near that (there are many optimization opportunities that are currently unexplored or unimplemented). And even with only a few optimizations, many FP implementations (GHC, OCaml, SBCL) are almost as fast as C already!

DarkShikari 17y ago

This is why, for instance, FORTRAN can easily outperform C for certain classes of program. Not quite. To quote the master: <pengvado> gcc fails to optimize it because gcc has always sucked at arrays <pengvado> that's *the* benefit of fortran The benefit of FORTRAN is due to array and aliasing issues in C, not really whole-program optimization.

malkia 17y ago
hence __restrict