On Monday, 11 August 2014 at 15:13:43 UTC, Russel Winder via
Digitalmars-d wrote:
For me, software dataflow architecture is processes with input
channels
and output channels where the each process only computes on the
receipt
of data ready on some a combination of its inputs.
Yes, but to get efficiency you need to make sure to take
advantage of cache coherency…
I think dataflow in combination with transactional memory
(Haswell and newer CPUs) could be a killer feature.
Václav Pech, myself and others been discussing the role of STM
but
haven't really come to a conclusion. STM is definitely a great
tool for
virtual machine, framework and library developers, but it is
not certain
is is a useful general applications tool.
Really? I would think that putting TM to good use would be
difficult without knowing the access patterns, so it would be
more useful for engine and application developers…?
You essentially want to take advantage of a low probability of
accessing the same cache-lines within a transaction, otherwise it
will revert to slow locking. So you need to minimize the
probability of concurrent access.
(I agree that CSP would be too much me too unless you build
everything around it.)
I disagree. Actors, dataflow and CSP are all different.
Although each
can be constructed from one of the others, true, but it leads to
inefficiencies. It turns out to be better to implement all three
separately based on a lower-level set of primitives.
I am thinking more of the eco-system. If you try to support too
many paradigms you end up with many small islands which makes
building applications more challenging and source code more
difficult to read.
I think dataflow would be possible to work into the range-based
paradigm that D libraries seems to follow.
C++ is good example of the high eco system costs of trying to
support everything, but very little out of the box. You basically
have to select one primary framework and then try to shoehorn
other reusable components into that framework by ugly layers of
glue…
