[Simgrid-user] Simulacrum and Java bindings scalability (was: SimuLaCrUM OOM Issues)
martin.quinson at loria.fr
Fri Jan 27 08:10:39 CET 2012
On Fri, Jan 27, 2012 at 06:29:31AM +0100, Thomas Bocek wrote:
> Hi Martin,
> On 01/26/2012 10:23 AM, Martin Quinson wrote:
> > I fear that improving on this would be quite a large work. Something
> > like recoding SimuLaCrUM in a language that I betterly master than
> > Java, or at least drop swing for a better UI toolkit (SWT?). I have no
> > real option there since the only language that I master is C and the
> > best toolkit candidate would be Qt. I dunno.
> I don't mind an ugly UI if it gets things done (of course it would be
> nice to have a good UI). From a users perspective it would be nice to
> have fewer choices with good default values in a simple view and in an
> advanced view, have more options with better documentation.
It's not ugliness issue. The toolkit induces an overall design through
the MVC modeling, and it also induces choices on data structures used
on the model side. I'm not saying that swing is inherently less
performant because of Java of something, but the tree data structures
that I use to store the promoters and filters are a pure pain to use.
And I must use them to have the swing trees. Swing is notoriously a
unfriendly graphical toolkit to work with.
And now, for the simgrid v3 platforms, I'd like to introduce rather
large changes (such as the ability to generate several AS separately
and generate their interconection), but getting simulacrum working the
way it is was so painful that I'm reluctant to modify it. I'd better
redoing it from scratch in a more coder friendly toolkit.
> > But the good news for you is that you don't really need simulacrum for
> > waht you plan to do. If you want to go for one million nodes (or so),
> > you have two approches:
> > * Use a cluster platform, something like:
> > * Use a peer platform, something like:
> > examples/platforms/syscoord/median_harvard.xml
> Great, thanks for the pointers! Probably a million peers with the Java
> bindings won't work. We'll see how many peers we can simulate.
Well. Simulating a million Java peers will certainly not work as is,
there is no magic here. But I'm really certain that we could getting
it working with a moderate development effort (something like 2 full
time weeks or one month). As discussed with Henri, I see several
possibilities to get a continuation or co-routine support in Java.
* Use an alternate JVM, such as Da Vinci Machine, which seems to
provide this support already.
* Use a bytecode rewriting solution providing this co-routine
feature, something like what the kilim framework provides.
* Do the context switching directly from the C code, assuming that
the JVM is perfectly reintrant.
The third solution, if possible, would be the best for us. We have JNI
already so there is no additional dependency. I'm dubious that it's
possible but this is what I understand from the "JNI continuations
trick" listed on following page.
If the JNI trick is actually not possible, I'm not sure of what I
prefer from to other solutions. One is more portable than the other,
but the choosing criteria will be stability, performance and
maintainability of the solutions.
As a first step, someone should try these solutions to see what's true
from what can be read on the internet. I'd love to do so myself, but
I'm not sure I'll find the time to do so in the next few months...
$sig = Mail::Signature->new;
More information about the Simgrid-user