computer language shootout

[brk@jenkon.com]

GHC ranks quite poorly currently. (I think there's an AWK implementation
that's ahead of it, nevermind Ruby or Python). There are still a couple of
benchmarks that haven't been implemented yet for Haskell, and a couple more
that don't make sense for a non-OO language. I spent a little while working
over the examples a month or two ago. I was able to shorten a number of them
considerably, and even sped up a few. My difficulty was that I was writing
for ghc-4.08 on Cygwin (Doug uses 5.02 on linux), so things that improved
the speed on my windows box often reduced the speed on Doug's linux box!

I'm still pretty new at Haskell, so it's probably worthwhile for some more
expert folks to take a look at all the current implementations.

I have to say (and this also relates to the newbie question thread) that I
don't understand why GHC fares so poorly, and I guess I find it a little
frustrating. It seems as though, by programming in Haskell with all its
great semantic properties and opportunities for optimization, the compiler
should be able to generate code that's enormously faster than the naive
implementation, and easily competitive with C (or at least Ocaml!). Does
anyone understand why this isn't the case now? Is it just that these things
take time and they're being worked on, or do the techniques for this level
of optimization not exist yet for lazy functional languages?

Bryn


> -----Original Message-----
> From:	Miles Egan [SMTP:miles@caddr.com]
> Sent:	Friday, July 27, 2001 7:55 AM
> To:	haskell@haskell.org
> Subject:	computer language shootout
> 
> I apologize if this question has already been asked, but I couldn't find a
> searchable version of the mail archive.
> 
> Doug Bagley's computer language shootout,
> http://www.bagley.org/~doug/shootout/,
> a collection of mini-benchmarks in several languages, doesn't paint a very
> flattering picture of GHC's performance.  GHC is even ranked below Ruby
> and
> Python!  Has anyone tried to optimize any of the GHC programs?  
> 
> Ocaml fares quite well in these tests and a glance at several of the Ocaml
> programs suggests that most of them have been fairly aggressively
> optimized.  
> These kinds of benchmarks are kind of silly, but also a good p.r.
> opportunity.
> 
> -- 
> miles
> 
> "We in the past evade X, where X is something which we believe to be a
> lion, through the act of running." - swiftrain@geocities.com
> 
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell