| David DiNucci 2006-04-08, 7:12 pm |
| Slawomir J. wrote:
> 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 cannot argue with such goals, since I've argued that ScalPL achieves
them, though likely not in the same way as you do. I don't know enough
about your approach yet to say what the similarities might be.
> 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.
As described in my paper at HICSS88, the source code for LGDF2 (an
ancestor of ScalPL) contained macros (in m4) which expanded into direct
actions on hardware locks on the Sequent machine we had back then. So
not only did it not rely on supervisory software, it didn't even rely on
a subroutine library. The preprocessor step determined, purely from the
connectivity of the components, how to minimize bottlenecks by
identifying collections of components (called "rivalries") that might
contend for resources and assigning each its own lock. Of course, that
was with a much more simplistic model than ScalPL running on UMA SMPs.
> 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).
If you can precisely describe the syntax and semantics for each
construct you are proposing, and when necessary how they interact with
constructs in existing languages that they are incorporated with, that's
"theoretical" enough for me. I've seen too many cases where "I know
what I mean, just ask me" together with lots of examples and protoypes
still leaves lots of holes and inconsistencies in the definition.
> 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. ;-)
There seems to be some confusion here between centralization and
layering. Even if lower layers talk to (or utilize) upper layers, it
can still be decentralized--e.g. if different parts of the lower layer
talk to different parts of the upper layer.
> Load ballancing issue goes out of play completely if granulity of the
> running translated code is high enough.
I don't know what you mean by that. If you have statically assigned
program components to platform nodes and different components are used
at different times during the execution, then so will different nodes
be, regardless of granularity.
> 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.
So, if I understand in the context of your earlier statements, even
though you don't want the entire diagram loaded to all nodes, you do
want each sub-diagram loaded to multiple nodes. It sounds like more a
matter of degree than of principle.
> In a larger picture, having anything centralized does leave the entire
> system volnurable to failure if anything associated with the centralized
> parts fails.
I think the potential advantages of decentralization are well
recognized, though there are plenty of people who believe that many are
unachievable or not worth the added complexity.
-Dave
|