[Haskell-cafe] Performance: MD5

[Peter Verswyvelen]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>