Kevin,
Interesting point.
Over the past few weeks as part of my work, I have interviewed a
large numbers of Haskell developers from many different industries
and have been hearing the same points you are making. Space leaks
that were address by learning how to use laziness and performance
issues cleared up by using strictness.
Also interesting is that in all my interviews, GHC performance was
never raised. No one said "I have to drop into C to solve that
performance problem."
Gregg
On 5/16/2012 1:44 PM, Kevin Charter wrote:
On Wed, May 16, 2012 at 8:40 AM, Gregg Lebovitz <glebov...@gmail.com>
wrote:
1) Does Haskell and its libraries need performance
improvements? Probably yes. Some of the performance issues
seem to be related to the way the language is implemented and
others by how it is defined. Developers really do run into
performance issues with Haskell and either learn to work
around the issue or try to fix the offending implementation.
The wiki performance page gives insight into some of the
performance issues and how address them.
I think there is a closely-related issue: that you'll need
to learn how to debug subtle performance problems early
in your Haskell programming career. In particular
- you will have space leaks and related performance
problems in naively-written programs
- you will consequently need to learn how to use
strictness annotations and other related language
features, and how to use the profiler to determine where
they're needed
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.
The example is contrived, but it's a very common task to
consume some big stream of input and produce a much smaller
summary of it. I think it's fair to say that you have to be a
slightly sophisticated Haskell programmer to do those kinds of
things correctly, at least compared to more mainstream
languages.
My experience is that this is perhaps the most important
'problem' with Haskell performance. Not so much that it's
typically two or three or ten times slower than language X,
but that it's easy to have a bad experience early on,
one that seems inconsistent with the language shoot-out and
other performance comparisons.
Kevin
--
Kevin Charter
kevin.char...@acm.org
|
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
