[bitc-dev] Call by need?

[wren ng thornton]

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
>> be....
>
> Umm. Nothing personal, but this is a straight line that I simple cannot
> resist...
>
> 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++[1], 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.


[1] 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:
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php
http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php
http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php

-- 
Live well,
~wren