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
On Fri, Jul 27, 2001 at 10:11:20AM -0700, brk@jenkon.com wrote:
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.
I think it's important to keep these benchmarks in perspective, though. As Doug Bagley himself says, these kinds of benchmarks are pretty hard to interpret and are subject to a lot of noise. Extrapolating performance on small artificial problems like this to real application performance is not at all straightforward. That said, this is a small p.r. problem. -- 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
Miles Egan (miles@caddr.com) wrote: [shootout] Before it starts to explode, can we move this thread to the Haskell Cafe? Regards, Marc -- Marc van Dongen, CS Dept | phone: +353 21 4903578 University College Cork, NUIC | Fax: +353 21 4903113 Western Road, Cork, Ireland | Email: dongen@cs.ucc.ie
On Fri, Jul 27, 2001 at 06:28:26PM +0100, Marc van Dongen wrote:
Miles Egan (miles@caddr.com) wrote:
[shootout]
Before it starts to explode, can we move this thread to the Haskell Cafe?
Happily. I apologize if this isn't the right list. It wasn't quite clear to me which list was most appropriate for this discussion. (followups to haskell-cafe). -- 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
participants (3)
-
brk＠jenkon.com -
Marc van Dongen -
Miles Egan