Based on my Domain Architecture approach (e.g. MC102) it is possible to design each components as either passive objects (as in the current MC102) or as active objects (>= 1 thread). This is easy because of loose coupling and using signals/delegates>We have done a POC in C# last week using asynchronous delegates and .NET tasks. It will be easy in C++ as well but a little more effort to wrap Boost Thread futures.To make the code more flexible we can always uses a Proxy, which also hides different h/w and s/w platforms.So, client components just communicate via asynch provides/requires interfaces, like hardware. To finish, we will need a state machine for each component for things like time outs, exceptions... In other words, the state machine is the gizzards of the delegate ports.Here is an example to get the gist of it (in this case with asynch delegates).

QuoteOriginally posted by: outrunsounds good Cuch! With all these various designs, the glue that organizes the parallelization and communication is always just a couple of lines of code.Can we say that the parallel designs have 4 element* a parallel rng* a distribution sampler that uses the rng to generate paths and sample measures. this is the QF part.* an accumulator that aggregates many samples into a small set of statistics* communication and job segmentation glue?Yes. Each component will have its I/O interaction with other components and once the signature is known we can then decide if the signals are synchronous or asynchronous. Component black-box internals are for the developer while the outside is for the plumber/gluer.In the above case you - as originator - would need to specify the provides/requires data flow in the component network and then you are more or less finished with the plumbing part.Must rush now; I wil post later.

QuoteOriginally posted by: outrunI'd like to know (investigate: scalability etc) of the two types of communication, push vs pull.E.g. if we have a controller that created N threads and asynchronous commnication, then the controller can either query (pull) the threads for results according to it's own schedule, ...or.. the threads can report results back to the controller (push).My hunch is that push is more scalable. E.g. if we think about 4 GPU with a total of 4.000 cores as an extreme yet reasonable case, then a flow model looks less complex and problematic.I think either solution will be sub-optimal because you seem to be focusing on one interaction in one or two components. RNG is not the issue. Try push, then pull and compare. What happened to ??Can we say that the parallel designs have 4 element* a parallel rng* a distribution sampler that uses the rng to generate paths and sample measures. this is the QF part.* an accumulator that aggregates many samples into a small set of statistics* communication and job segmentation glue

Quote How many more interacting components do you see? No idea, just the ones you wrote down. It is for you to scope and unambiguously define the problem I reckon. After all it is the informal description of your application. Look at MC102, for example and you see 6 components separated by interfaces.QuoteYou are on the other hand talking about design patterns. That bit is language and personal preferences specificNope. It is language-independent and the patterns have been around for ages. That's the whole point of OP. Amusing perspective on design patterns; many CS people I know don't use them while many software product developers use them as much as possible. What's the reason?Just reiventing the same software wheel each time seems so wasteful of one's time.QuoteSo my view is more about algorithms and data exchange, the view of "The Art of Computer Programming"Fair enough. I am an engineer. I am talking about software design of complex systems in this thread everything must be designed.

Quote* The PRNG for me is an essential algorithm irrespectible of the implementation, we need independent random streams (because we don't want needless communication, synchronization, locking) between asynchronous parallels elements.* The distribution is an algorithm too. It consumes random numbers and generates samples from a specific distribution.* The aggregator is an algorithm too. It combined the generated parallel statistics into an overall statistics. This is the bit about palpable algorithms and stream processing* finally -depending on the type of parallelism- there will be a step where the parallel jobs throw of the results to the aggregator. This is data exchange. When using threads or MPI this is asynchronous communication, (or synchronous build on top of that with waiting). For CUDA that might be different, I don't know yet.How do you make this description unambiguous? Now it is a wish list / set of features.

QuoteAn algorithm is unambiguousReally? For every algo problem, I reckon 50 possible solutions determined by memory constraints and processing time.Software is still an artform and don't let anyone tell you otherwise

To get back on track, this particular thread is designing and implementing parallel systems. So, how to do this in general. Take examples by all means, but the focus in on how to do it in general. I like when we can use C#, C++ tools to do the plumbing for the developers. In this thread we would also like is librtaries as black boxes, as parts of applications. More a software approach, numerics has other threads.