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 <[EMAIL PROTECTED]> wrote:
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:[EMAIL PROTECTED] _______________________________________________ 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
