[bitc-dev] Call by need?
wren ng thornton
wren at freegeek.org
Fri Sep 10 12:32:36 PDT 2010
On 9/10/10 1:34 AM, Jonathan S. Shapiro wrote:
> On Thu, Sep 9, 2010 at 8:15 PM, wren ng thornton<wren at freegeek.org> wrote:
>> Meh. As a practicing Haskeller, my experience is that the performance
>> characteristics aren't nearly as arcane as newcomers make them out to
> Umm. Nothing personal, but this is a straight line that I simple cannot
> As a practicing Haskeller, you've already decided that giving up a factor of
> 4x to 10x in performance is perfectly okay in the service of the Gods of
> Abstraction, so discussions about performance of Haskell are pretty funny.
> What I especially love about Haskell performance arguments is that they
> invariably put a top-20 Haskell coder up against some piece of code written
> by a run of the mill C programmer. Think about that.
The programs I've written are 2~4x the speed of C or 1~4x C++, with
the low end being for "real" programs (i.e., large-scale NLP work) and
the high end being for things that C is extremely specialized in. The
only code I compare mine against is my peers: researchers in NLP and PL,
both corporate and academic. They're the folks I have to compete with
for publication, so it doesn't much matter what percentile of coders
they happen to be in.
For me, ~2x is a perfectly acceptable overhead for ensuring static type
safety, separating pure code from side effects, removing segfaults,
allowing the code structure to model the problem domain, and reducing
LOC by many orders of magnitude. Laziness is an important factor in
providing all that, but it's hardly the only one. I've yet to see any
measurement of how much of the running time cost comes from laziness as
opposed to other abstractions like garbage collection, using a uniform
data representation (the STG), or pervasive use of HOFs. Considering
some of the early benchmarks for JHC vs GHC, the uniform representation
of data seems to be the major performance cost.
I do not expect abstraction to come for free, but I am willing to
recognize that there's a lot more to real world programs than small
constant factors of CPU cycles. The only place 2x CPU cycles matters in
practice is when dealing with hard real-time programs, puny
microcontrollers, or programs whose running time is already measured in
days and weeks. That last batch includes most NLP code, but then again a
lot of NLP code is written in Python precisely because it is more usable
than C++, so even they are willing to spend extra weeks of compute time
simply to make the code more legible and high-level.
 My numbers are borne out by some notorious competitions which are
often cited both for and against Haskell, despite how benchmarking
competitions pervert code far away from normal patterns:
More information about the bitc-dev