🚀 go-pugleaf

In article <4812@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:
>My small bet for the 90's is [...]
>Tools for writing parallel
>and distributed code??

As I understand it, the 'tools for writing parallel code' are already
available, to the extent that we have 'tools for writing code'
(though obviously the quest for developing 'better tools for writing code'
will continue).  The point is the programmer should not *have* to
specify the parallelism-information in his program.  The programmer
already has too much to worry about in codifying the problem in the
programming language, without having another housekeeping task thrust
upon him.  We have machines to take on our housekeeping work.
The declarative programming languages seem (opinion) to be one of
the most promising ways to allow the machine to find its own parallelism
information without the programmer having to go to any special lengths
to allow for it.

Having said that, your original point is right to the extent that the
corollary of what you actually seemed to say is the problem:
how to keep the code from distributing too freely, and too far,
across the system (again, of course, a task which should be performed
mechanically, not added as a burden on the programmer).  The harnessing
of 'locality' is perhaps the main stumbling block for most multiprocessor
research machines.  Use of 'locality' is, and always has been, the most
important thing to get right if one hopes to achieve high performance
(witness the effect of adding banks of general purpose registers,
cache memory, etc in conventional machines).  This is, and will always be,
a prime place to focus research effort.

Malcolm Shute.         (The AM Mollusc:   v_@_ )        Disclaimer: all