[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