[Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results

[Josef Svenningsson]

Andre,

I very much enjoyed reading your blog entry. I would like to make a few 
comments.

First of all I heartly agree with what you call "the main problem". I 
quote: "The main problem I see with all this is that it’s just too hard 
for an average Haskell programmer to get good performance out of 
Haskell". This is just so true and something which we need to do 
something about. What I would like to comment on is why we have this 
problem and what we can/should do about it.

Why is it difficult to write good performance Haskell programs? Well, 
I'm not going to try and discuss this general question but focus on I/O 
since that is what this thread is really about. So let's formulate the 
question to: Why is it difficult to write good performance I/O in 
Haskell? From your blog entry I take it that you think that there is 
something wrong with the language Haskell. Maybe I misinterpret you but 
this is how I read it. I don't quite agree with this. What *is* true is 
that it is difficult to write good performance I/O in any of the 
*implementations* that we have. And this is ofcourse a shame. I think 
this is partly because fast I/O hasn't been that high a priority. I 
recall an email dating a few years back where Simon PJ was saying that 
they haven't spent that much time on making I/O blazingly fast. So 
perhaps bringing the issue on the table and making the implementors 
aware of it will improve on the situation.

Although I do not believe that the Haskell language itself is to blame 
for why it's difficult to write decent performing I/O, the standard 
libraries might be a problem. It may be that the functions they provide 
are difficult to make efficient and that they encourage abuse. One 
particular function I have in mind is getContents. Maybe we need another 
set of functions which while still being highlevel are much easier to 
implement efficiently. Work in this direction has already started with 
the BlockIO library. I think this is an exciting and promising route to 
take. Andre, you suggest adding syntax to help the programmer writing 
faster code. Somehow I don't think that is the right way to go, even if 
it is only my gut feeling. I think this problem can and should be solved 
on the library level rather than on the language design level. But I 
might ofcourse be wrong.

Ok, enough preaching for today. For the record, I also recommend O'Caml 
rather than Haskell to my performance-aware friends.

/Josef

Andre Pang wrote:

> On 29/09/2004, at 8:41 AM, Graham Klyne wrote:
>
>> I can see that this requires the original file to be kept for 3-time 
>> scanning, so enough memory for the entire file will be required. Is 
>> that *the* problem to which you allude? I can't see any other problem 
>> here. And why would this put Haskell at a disadvantage?
>
>
> I've been watching this thread with interest, and posted my own 
> thoughts on this thread and Haskell's performance in general as a blog 
> entry. Rather than repeat it all here, I'll post a link to it:
>
> http://www.algorithm.com.au/mt/haskell/haskells_performance.html
>
> 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 you have to be a 
> Haskell expert to do so. One possible solution may be to allow for 
> some extra, syntactically integrated declarations to be inserted by 
> the programmer which enables much better optimisation (e.g. see how to 
> write unboxed strict array example in Clean: much more clear and less 
> work than using IOUArrays). Performance is the one major reason I 
> recommend many existing C programmers try out O'Caml rather than 
> Haskell as their first functional programming language, and it would 
> be really nice if optimisation was made a bit easier.
>
>