[Ns-developers] GSOC - Parallel Simulations | First ideas

[Hagen Paul Pfeifer]

On Tue, 25 Mar 2008 06:16:40 +0100, Mathieu Lacage
<mathieu.lacage at sophia.inria.fr> wrote:
> hey,

Howdy!

> I think that designing an abstraction layer like this would be nice but
> that your first goal should be to try to get something running. i.e.,
> once you have gotten the thing to run with some speedup, you can try to
> design an abstraction layer. So, I would put this as a last
> nice-to-have-but-far-from-vital step of your project.

Let me clarify: the additional abstraction level is planned for
stage two (hopefully within gsoc ;)! Of course, the development model
should be incremental and produce first some results. No question about
that!
Also, it is not possible to add an additional layer without further
knowledge
and within an development stage where the API can't be stable! In contrary 
it is complete brain dead to bring in an API which is mutating every day.
After all: I thought this assumption was as a matter of course - next time
I will explain the steps more detailed.

Anyway: it is not my first piece of software! Since some years I am
familiar
with the "basics" of development ... ;)

>> o In the first part an profiling analysis (code coverage test, oprofile,
>   et cetera,.)
>>   to detect CPU hogs to understand where processing power is consumed.
> Use this
>>   information to find approaches to split workload into several pieces.
>>   Currently my knowlendge is limited in this sector an may help me where
> are
>>   the major CPU hogs.
>>
>>   - Spot causal dependencies within the model like global variables. Dig
> into
>>     major components (like wireless node dependencies, like radio
>>     interference, et cetera,). Categorize these into several groups to
> spot out
>>     the parallelization possibilities.
> 
> It is, indeed, a great idea to take a fresh look at the overall problem
> and to try to find optimization opportunities anywhere you can. However,
> there are a couple of things which I think you should consider: a very
> important characteristic of a final working system is that even though
> it might not take the most out of the hardware, it should not require
> model developers to be aware of parallelization or to have to think
> about it. Because, let's be honest: experience shows that model
> developers have barely enough time and energy to develop good
> non-parallel models so, they never try to build parallel models.

Full-ACK, sorry for the misunderstandings that I introduced. I mentioned
some technical aspects but forget on the other hand the overall picture!

> So, if I were you, I would start by reducing the scope of your project
> to ignore the investigation of intra-node parallelization opportunities
> because the data-dependence analysis of intra-node code will be hard and
> trying to disentangle it will most likely have a very big impact on
> model design which, as I mentioned above, is a very big minus.

Right! To bring some light in: my idea is that the introduced
parallelization
algorithm should technical not so far away from a distributed approach. The
treading via POSIX threads IS suitable! Consider this as an pro for the
threading
approach.

> A simple assumption which is then often made is that the only
> data-dependency across nodes is packets flowing along channels which
> connect nodes (i.e., no global variable is used to exchange data between
> nodes). This makes the data-dependency problem much easier to analyze
> because it is reduced to know the physical connectivity of nodes through
> channels. So, I think that you could start from there, but that is just
> me :)

Hopefully! ;)

> hopefully, ns-3 and your proposal will get out that alpha state soon !

Me too! ;)
 
> Mathieu

HGN