Why is Haskell (GHC) so darn fast?
<p>Haskell (with the <code>GHC</code> compiler) is a <a href="https://wiki.haskell.org/Why_Haskell_matters#The_speed_of_Haskell" rel="noreferrer">lot faster than you'd expect</a>. Used correctly, it can get close-ish to low-level languages. (A favorite thing for Haskellers to do is to try and get within 5% of C (or even beat it, but that means you are using an inefficient C program, since GHC compiles Haskell to C).) My question is, why?</p>

<p>Haskell is declarative and based on lambda calculus. Machine architectures are clearly imperative, being based on turing machines, roughly. Indeed, Haskell doesn't even have a specific evaluation order. Also, instead of dealing with machine data types, you make algebraic data types all the time.</p>

<p>Weirdest of all though is higher order functions. You would think that creating functions on the fly, and throwing them around, would make a program slower. <a href="https://hbtvl.wordpress.com/2015/12/14/efficient-parsing-of-large-text-files-part-4-and-conclusion/" rel="noreferrer">But using higher order functions actually makes Haskell faster.</a> Indeed, it seems that, to optimize Haskell code, you need to make it more elegant and abstract instead of more machine-like. None of Haskell's more advanced features seem to even <em>affect</em> its performance, if they don't improve it.</p>

<p>Sorry if this is sounding ranty, but here is my question: <strong>Why is Haskell (compiled with GHC) so fast, considering its abstract nature and differences from physical machines?</strong></p>

<p>Note: The reason I say C and other imperative languages are somewhat similar to Turing Machines (but not to the extent that Haskell is similar to Lambda Calculus) is that in an imperative language, you have a finite number of states (a.k.a. line number), along with a Tape (the ram), such that the state and the current tape determine what to do to the tape. See the Wikipedia entry, <a href="https://en.wikipedia.org/wiki/Turing_machine_equivalents" rel="noreferrer">Turing machine equivalents</a>, for the transition from Turing Machines to computers.</p>