[Haskell-cafe] Performance: MD5

Andrew Coppin andrewcoppin at btinternet.com
Sun May 18 12:04:52 EDT 2008

Peter Verswyvelen wrote:
> As a side note on this discussion, isn't it so that the current CPU 
> hardware evolved in such a way that it is better suited for imperative 
> programs? (I'm not talking about the GPU, that's another story). I 
> mean, hardware gets optimized to run applications faster, but these 
> applications are mainly written in C/C++, so you get a nice feedback 
> loop here...
> Is it possible to design hardware that is better suitable for 
> functional languages?

I wondered about that myself a few times.

For example, current computer designs revolve around a single complex, 
fast CPU connected to some slow RAM. [Or, more recently, a very small 
number of seperate CPUs.] I wonder what would happen if you instead had 
a vast number of very simple proto-processors connected in a vast 
network. [But I'm guessing the first thing that'll happen is that the 
data is never where you want it to be...]

At any rate, custom hardware vs IA32 is rather like GHC vs GCC - one has 
been around for a hell of a lot longer, and had vastly more R&D thrown 
at it. Unless you can find some crucial insight that gives you a very 
big advantage, you're not going to get anywhere near the market leader 
with anything you can come up with by yourself.

(It does seem to be that the major trouble with modern processors is 
that they only go fast if there are no cache misses. Back in the days 
when RAM was as fast as CPU, you could structure your program any way 
you like and it would just work. Today you have to jump through loops to 
make sure the cache behaviour is good, or you can just forget it and go 
home now. That tends to be a pretty big problem for any programming 
language with automatic memory management - Java immediately springs to 
mind, but of course Haskell is in the same boat. I get the vague 
impression that hardware designers are starting to take notice of the 
problem, but it's difficult to see how they could design anything 
differently. We'll see I guess... Certainly if hardware appears that 
handles OOP languages better, it's likely to handle Haskell better too.)

More information about the Haskell-Cafe mailing list