<story><title>Haskell as fast as C: working at a high altitude for low level performance</title><url>http://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-c-working-at-a-high-altitude-for-low-level-performance/</url></story><parent_chain></parent_chain><comment><author>bo1024</author><text>This is very cool, but it still makes me extremely skeptical. In brief, the more posts of this type I see, the more I&apos;m implicitly being convinced that writing performant code in high-level languages requires a series of tricks that get around the &quot;natural&quot; or &quot;naive&quot; way to write the code. The impression I get is that high-level languages allow you to express your thoughts concisely, or they perhaps allow you to mimic the performance of low-level languages, but not both at the same time.&lt;p&gt;Notice that it takes an entire blog post to use Haskell to emulate the performance of a straightforward 20-line C program that can be written in under 60 seconds. There are high-performance tasks which are practically trivial in an imperative language but which merit a conference paper when accomplished in Haskell.&lt;p&gt;So it&apos;s hard to see something like this as an argument that higher-level languages are simplifying anything.</text></comment>
<story><title>Haskell as fast as C: working at a high altitude for low level performance</title><url>http://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-c-working-at-a-high-altitude-for-low-level-performance/</url></story><parent_chain></parent_chain><comment><author>duaneb</author><text>Having seen hundreds of these types of blog posts, touting faster-than-c (superluminal?) benchmarks in arbitrary languages, I&apos;m extremely skeptical. Real-world applications are rarely solely limited by small chunks of code that are simple enough to be optimized independently of the rest of the program. Accurate comparisons should be done on large, complex code bases that mirror an equivalent C program.&lt;p&gt;Unfortunately, those don&apos;t exist, so in my mind the true performance potential of haskell is still unknown. I do have high hopes for the language, especially since whole-program optimization and aggressive inlining/code folding should yield very, very efficient code, but as of yet &lt;i&gt;the only large programs in haskell remain GHC and darcs&lt;/i&gt;, and darcs is extremely slow.&lt;p&gt;Still: a single benchmark showing a good result is better than one showing a bad result.</text></comment>