[Haskell-cafe] Re: Hardware

[Neil Davies]

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 <bulat.ziganshin at gmail.com> 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:Bulat.Ziganshin at gmail.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>