[Haskell-cafe] saner shootout programs

[Sterling Clover]

Well, it would be meaningful for your own experience in learning Haskell.
Some time ago somebody took a shot at nbodies using pure immutable
structures, and as I recall, got within about 4x the performance of mutable
structures. In 6.6, an STArray based approach was maybe 2x slower, but by
now it may well be comparable, as Dons pointed out. In fact, lots of the
shootout entries could use an overhaul now that 6.8 is running on their
machines, as plenty of older, uglier, optimizations are probably preformed
as efficiently if not more so by the newer GHC, whose strictness analysis,
for example, is consistently and pleasantly surprising.

If you take a stab at some of these benchmarks, with some helpful guidance
from #haskell, you'll no doubt get a much better sense of how memory and
performance works in haskell, and which tweaks are just there for the last
2%. So even if you can't beat the current winners (and given the compiler
changes, you may well be able to) you'll still come out ahead in the
process.

As for the clean entry though, it no doubt relies heavily on uniqueness
typing and so is secretly mutating like crazy under the hood.

Cheers,
S.

On Tue, May 13, 2008 at 12:26 AM, J C <jhc0033 at gmail.com> wrote:

> On Mon, May 12, 2008 at 4:38 AM, Richard Kelsall
> <r.kelsall at millstream.com> wrote:
>
> >  Hello JC, I think you've set yourself a challenge there :) Welcome to
> >  Haskell programming. Taking a Shootout entry and playing with it is
> >  a great way to learn Haskell. The Shootout provides an example in your
> >  favourite previous language for comparison and a small well defined
> >  program with exact test results you can pit your wits against. Fame
> >  awaits you for a fast and beautiful entry. I'm still learning useful
> >  things from the Fasta benchmark. It's surprising how many interesting
> >  things you can discover in a small piece of code.
>
> It may be fun, but I don't think it would be meaningful. My code will
> be, most likely, slow, leaving some doubt as to whether it's slow
> because of the limitations of the compiler or my inexperience.
>
> On the other hand, if the experts can't help using malloc, unsafe*,
> global mutables and IO, I'll be able to conclude that this is probably
> what it takes to make Haskell run fast :-(
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/575755c3/attachment.htm