On 9/10/10 1:34 AM, Jonathan S. Shapiro wrote: > On Thu, Sep 9, 2010 at 8:15 PM, wren ng thornton<[email protected]> 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 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
