Yes, some things might be good for both language paradigms, e.g.
* hardware garbage collection
* hardware transactional memory
With a bit of Googling, both seem to exists, the latter even being
supported by SUN
Andrew Coppin wrote:
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.)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
