[Haskell-cafe] Re: Haskell Speed
bfulg at pacbell.net
Mon Jan 2 12:25:56 EST 2006
-----BEGIN PGP SIGNED MESSAGE-----
> I recently stumbled across this thread, related to the Shootout
> (which I run) and wanted to add a few comments.
> First, I agree that I am a Haskell novice; however, I rely on
> people like yourselves to show me where I am doing things wrong.
> If our solutions are horribly inefficient, please tell us what we
> can do to resolve the problem. But note that in some cases, we are
> purposely being inefficient so that we can measure the cost of
> certain basic operations.
> Doug Bagely started the Shootout as a comparison of scripting
> languages. After I revived it, I started focussing more on
> functional and logic languages, since I was curious how these
> languages would fare in comparison with the more typically-used
> languages like C/C++. Consequently, many of the tests show this
> heritage and are highly imperative. We have been working to relax
> some of these rules, and have added many new tests that try to be
> more amenable to comparison of lazy and 'strict' languages.
> In our defense I would like to plead that it is not easy to devise
> short problems (e.g., that can be expressed in a page or so of code
> - -- we try to limit it to 100 lines of C++ code as a rough
> benchmark), and that also take enough run time for a meaningful
> measurement. So, many of the tests initially suffered from foolish
> looping and repetition as a means of extending the run times
> sufficiently to allow measurement. We have been changing tests so
> that fewer of them rely on these kinds of activities to generate
> results. We are always interested in new ideas, and would consider
> any benchmark ideas you have.
> Finally, I don't agree at all that Haskell's scores show poorly.
> The GHC compiler is one of the better performers, and regularly
> trounces other languages when we let it do its job. For example,
> we had to jump through many hoops to convince the compiler to
> actually invoke all the loops required to do the "same way" tests
> on methodcall and similar benchmarks, because the compiler was so
> sharp at identifying wasted effort and optimizing it away. Perhaps
> we don't say this strongly enough on the site, but I was truly
> impressed at its ability to toss aside wasted calculations and
> focus on the core problem. I'll admit it was frustrating because
> we wanted to see how long it would take for Haskell to make N
> recursive calls, or what have you, but the fact that the compiler
> saw that there was no need to do the recursion to get the result is
> quite amazing! I'm sure this would be extremely useful when
> compiling real-world programs.
> There have been many cases where the "obvious" solution in Haskell
> is a great performer, but we discover that it's so fast because it
> has tossed aside wasted cycles and just done the work necessary to
> arrive at a solution. It's unfortunate, since we then have to
> dirty the program with wasted steps to force it to exercise the
> tasks required. But in a "real world" test I think Haskell would
> show quite well.
> As we evolve into the newer tests, I think you will see Haskell
> make a better showing. Simon Marlow (and others) have been a huge
> help in optimizing the existing tests in a "fair" fashion, and as
> we provide more "same thing" type tests, I think Haskell will pull
> further ahead.
> - -Brent
> P.S. I must say that I find Haskell to be the most esthetically
> pleasing language -- it's quite beautiful when printed!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
-----END PGP SIGNATURE-----
More information about the Haskell-Cafe