[Haskell-cafe] Can Haskell outperform C++?

Ben Gamari bgamari.foss at gmail.com
Wed May 16 22:00:25 CEST 2012


Kevin Charter <kcharter at gmail.com> writes:

snip
> For example, imagine you're new to the language, and as an exercise decide
> to write a program that counts the characters on standard input and writes
> the count to standard output. A naive program in, say, Python will probably
> use constant space and be fairly fast. A naive program in Haskell stands a
> good chance of having a space leak, building a long chain of thunks that
> isn't forced until it needs to write the final answer.  On small inputs,
> you won't notice. The nasty surprise comes when your co-worker says "cool,
> let's run it on this 100 MB log file!" and your program dies a horrible
> death. If your friend is a sceptic, she'll arch an eyebrow and secretly
> think your program -- and Haskell -- are a bit lame.
>
I, for one, can say that my initial impressions of Haskell were quite
scarred by exactly this issue. Being in experimental physics, I often
find myself writing data analysis code doing relatively simple
manipulations on large(ish) data sets. My first attempt at tackling a
problem in Haskell took nearly three days to get running with reasonable
performance. I can only thank the wonderful folks in #haskell profusely
for all of their help getting through that period. That being said, it
was quite frustrating at the time and I often wondered how I could
tackle a reasonably large project if I couldn't solve even a simple
problem with halfway decent performance. If it weren't for #haskell, I
probably would have given up on Haskell right then and there, much to my
deficit.

While things have gotten easier, even now, nearly a year after writing
my first line of Haskell, I still occassionally find a performance
issue^H^H^H^H surprise. I'm honestly not really sure what technical
measures could be taken to ease this learning curve. The amazing
community helps quite a bit but I feel that this may not be a
sustainable approach if Haskell gains greater acceptance. The profiler
is certainly useful (and much better with GHC 7.4), but there are still
cases where the performance hit incurred by the profiling
instrumentation precludes this route of investigation without time
consuming guessing at how to pare down my test case. It's certainly not
an easy problem.

Cheers,

- Ben




More information about the Haskell-Cafe mailing list