| Slawomir J. 2006-04-08, 7:12 pm |
| "David DiNucci" <dave@elepar.com> wrote in message
news:nP-dnevBetOoOKzZ4p2dnA@comcast.com...
> In general, the issue is not black and white. You can implement even
> purely sequential models by starting a thread for each operation and have
> each one poll the previous until (when it is finished) executing itself.
> I think the real issue you are trying to capture is not whether an
> implementation uses centralized servers, etc., but what sorts of
> dependences exist between program operations, and how to break the
> unneeded ones, and express and efficiently implement the important ones,
> so that only the important ones come into play during execution.
I agree - doing this would merely replicate pure dataflow computing hardware
which never got beyond very narrow area of application.
This is not what I am doing. The model I proposed allows linking routines
the same way electronic components are connected. This means that when the
routines being linked are very short, this replicates dataflow model for all
practical purposes. When the routines are large, it becomes merely
substitute for routinely used rudimentary control tools (semaphores,
critical sections, mutexes) to communicate between say a main thread and
"worker threads". The whole key to the concept is that the same low level
model covers both ends of the spectrum, allowing to cover all the space in
between control-flow and dataflow, which was not possible before.
I am aware that some of similar goals were pursued in other projects,
however, they almost always put a massive layer of translation/supervisory
software between what user enters and what the hardware does at the end.
This is what made these techniques usable for many end user applications,
but never for writing professional software that required top performance
(say operating systems, real time controlers, device drivers, etc, etc). My
background was mainly with writing such high-performance real-time software.
In this area especially, where timings of things are essential, it is almost
impossible to use any programming model that uses translation/supervisory
software that completely reorganizes what the user enters before it becomes
physically running code.
This is the reason I have attempted to turn things upside-down, so to speak.
Rather than start with purely theoretical model, I started with the
implementation (or actually quite a few of them before I got it to perform).
The goal was to be able to have massively parallel code that could run on
multiple processors absolutely without need of any centralized supervisors,
or complete reorganization from programming model into entirely different
execution model. I started with the implementation and arrived with the
model that would fulfill the needs. On the way (I think) I doscovered what
made the dataflow-like theoretical models to be often unable to translate
diagrams into decentralized parralel code.
I always considered anything centralized in both computing and real life to
be more often than not an impediment rather than help. Maybe it is the inner
Polish anarchist in me talking. ;-)
> FWIW, yes, what you are requesting is quite possible with ScalPL, but that
> doesn't mean it's necessarily desirable in ScalPL or any other model.
> Statically mapping the elements of your computation onto elements of your
> platform can leave you very vulnerable to load balancing issues (within
> the same application or when sharing resources with other applications),
> to faults, to intentional withdrawal of borrowed resources, etc.
Load ballancing issue goes out of play completely if granulity of the
running translated code is high enough. As to redundancy/fault tolerance, I
do deal with the issue in my specification as well. Sound support for user
defined parallelism allows replicating computation paths and relaying on one
of them making through.
In a larger picture, having anything centralized does leave the entire
system volnurable to failure if anything associated with the centralized
parts fails. Consider, controllers for large real-time systems like modern
cars or planes. It is absolutely paramount there that the lower level
components can still do their work and communicate with one another even if
the main supervisory node is out of action. It would be nice if our personal
computers could have that kind of reliability too. As it is today, a single
failure of some OS GUI call often brings everything else down.
Very Best Regards
Slawomir J.
info@stressflow.com
|