amount of work required to do this is much much more than amount of work required to write optimal C/asm code
I'm sorry, but no it's not. I've been using Haskell for a little under two
years now, and I'm already able to produce programs with significantly less
pain which outperform the C equivalents. Sure, if I pour a lot more time and
head scratching into my C, then I can probably beat my Haskell, but I just
don't have the time (or the need) to introduce pointer tagging, lazy
evaluation, and referential transparency transparency to my C code.
Any way, this thread has lost any usefulness.
On Tue, Sep 23, 2008 at 5:32 AM, Bulat Ziganshin
Hello Sterling,
Tuesday, September 23, 2008, 5:13:57 AM, you wrote:
Oh, and it "simply and naively" loops with the following: while (fgets_unlocked (line, MAXLINELEN, stdin)) If Bulat's point is that the shootout has inspired work on Haskell performance, and in the stdlibs no less, then lovely, and that's all to the good. Below every high level interface is lots of low level pain.
functions used to make C code faster is obviously worse than those used for Haskell code. just look - Clean gets 2x better performance than C
If his point is anything else, this is getting absurd.
my point is very simple - these tests says nothing about real performance since these tests was hardly optimized including adding special functions to ghc libs. amount of work required to do this is much much more than amount of work required to write optimal C/asm code
and this work obviously doesn't speed up every Haskell program. so that we have in Haskell world now is heroic efforts to speed up shootout test which doesn't say anything about real Haskell performance. what we have on prcatice is 10-20% speedup of ghc 6.8 and several libs which may improve speed in some usages
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- /jve