Bulat
That was done to death as well in the '80s - data flow architectures
where the execution was data-availability driven. The issue becomes
one of getting the most of the available silicon area. Unfortunately
with very small amounts of computation per work unit you:
a) spend a lot of time/area making the matching decision - the what
to do next
b) the basic sequential blocks of code are too small - can't
efficiently pipeline
Locality is essential for performance. It is needed to hide all the
(relatively large) latencies in fetching things.
If anyone wants to build the new style of functional programming
execution hardware, it is those issues that need to be sorted.
Not to say that Haskell is the wrong beast to think about these things
in. It's demand driven execution framework, and it's ability to
perform multiple concurrent evaluations safely are the unique points.
Neil
PS if any of you really want to attack this seriously - do get in
touch - I've got notes and stuff from the '80s when we (at Bristol)
looked into this. I've also got evaluation frameworks for modeling
communication behaviour and performance (which you'll need) -
naturally all written in Haskell!
On 02/06/07, Bulat Ziganshin
Hello Jon,
Friday, June 1, 2007, 11:17:07 PM, you wrote:
(we had the possiblity of funding to make something). We had lots of ideas, but after much arguing back and forth the conclusion we reached was that anything we could do would either be slower than mainstream hardware or would be
this looks rather strange for me. it's well known that Neuman architecture is a bottleneck with only one operation executed each time. it was developed in 1946 because those times all programming was in binary code and simplicity of programming was favored
but more efficient computational model exists. if cpu consists from huge amount of execution engines which synchronizes their operations only when one unit uses results produces by another then we got processor with huge level of natural parallelism and friendlier for FP programs. it seems that now we move right into this direction with GPUs
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe