Post by A..L.On Sun, 7 May 2006 14:49:06 +0200, "Slawomir J."
Post by Slawomir J.For those who can spare the time to look at it - I would appreciate all
comments and suggestions.
http://www.stressflow.com/cpt_introduction.htm
What is "new" here?...
[To Slawomir, the OP: This is a good reason for cross-posting instead
of just posting separately to two different groups.]
There has been a little extra discussion of this on comp.arch, but I
don't know if that will answer your question or not.
People have been looking at the call tree for a long time as a possible
source of parallelism, since for even a sequential program, the call
tree looks like things are "branching out". If one could just make the
branches (called functions) execute concurrently, problem solved! The
problem, of course, is that the branches in a call tree are only rarely
independent: They are actually sequenced by control and/or data
dependences which are not usually depicted in the tree.
So, this stressflow is apparently an attempt to bifurcate each called
module into a "stressed" section, which satisfies control and data
dependences for the caller, and a "relaxed" section (a new thread),
which is then free to go off and execute in parallel.
But: Why should we expect that the stressed section can satisfy
dependences for the caller? Usually, the caller wouldn't have called
the module unless it wanted something from it. Stressflow seems to
offer two ways for stuff to come back: (a) through the parameter list,
from the stressed section, and (b) through a downstream call to a common
routine by both the relaxed section's thread and the calling thread. It
seems pretty complicated to keep track of data and control dependences
in the latter case. In my perhaps-biased opinion, it would make more
sense to just model the desired control and data dependences from the
beginning and execute those (as one does in, say, ScalPL).
-Dave
---
http://www.elepar.com/