[Haskell-cafe] Re: OCaml list sees abysmal Language Shootout
Ronny Wichers Schreur
ronny at cs.ru.nl
Thu Oct 7 09:34:37 EDT 2004
Andre Pang writes (in the Haskell cafe):
> The executive summary of my thoughts is that it seems to be
> entirely possible to optimise Haskell to be competitive with
> other, more performance-focused languages, but it's hard...
and from his blog:
> if you need speed, you can get it in Clean much more easily
> in than Haskell.
Perhaps Clean gives your more fine-grained control over the
memory and execution behaviour of your program, but this is
normally at the expense of clarity and elegance of your program.
This is where I think we (FP-ers) stand: We can write elegant
programs and we can write efficient programs, but combining
these two aspects is still difficult. The Haskell and Clean
entries in the Language Shootout clearly demonstrate this.
Here are some ideas to better combine elegance and efficiency
- decouple data and functions
It's often easy to make choices in the data structures
with an eye to efficiency, for example sometimes it's
better to unbox elements (faster access), sometimes it's
better to share the elements (use less memory). The
programmer should be able to make these decisions without
changing the functions that use the data structure.
Overloading can help, but perhaps a good implementation
of views will improve it further.
- more compiler optimisations
Preferably the optimisations should be reasonably predictable
for the programmer.
- programmer guided transformations, optimisations
I don't think we'll ever reach the state where compiler
optimisations can completely bridge the gap between
elegance and efficiency. I don't mind giving it
some help, but I'd like to keep my original program.
For example, tell the compiler to unfold a function once,
so that the function is strict in more arguments in the
> [In Clean] you can, for example, make an unboxed, strict array
> just by writing [# 1, 2, 3 !] rather than [1, 2, 3]
I call [# 1, 2, 3 !] a tail-strict list with unboxed elements
(it doesn't have constant time access).
Ronny Wichers Schreur
More information about the Haskell-Cafe