Re: [simspark-devel] SimSpark boosting project

[Sander v. D. <sgv...@gm...>]

Hey Joschka,

Thanks for your reply. I didn't know about TBB, I will have a look into it.
I found a partly copy of the book online, but of course the part about ODE
is missing :) I will see if I can find it.

Regarding Bullet, I totally agree that for the future that is probably the
way forward. However, we hope to have these improvements ready for Istanbul,
and preferably for the German and Iran Open too. Using a different physics
engine will most likely change the dynamics, having most teams probably have
to recreate/relearn their movements. It would not be good to throw that onto
them on such short notice. Probably the best time to make this switch is
when we use new models/heterogeneous agents, when everybody has to start
over anyway. So that's why I am focusing on ODE now, the dynamics should
stay the same and it seems like there are relatively straightforward ways of
parallelising it. However, that is not a argument against already making a
start with Bullet now, and I have started taking a look at the API, to see
how well it fits the interfaces we now have after Andreas' very useful work.

About the integrated agents, that is a good idea! I will try to include
those in my tests.

Thanks again,

Sander

On Sat, Feb 19, 2011 at 6:08 AM, Joschka Boedecker <
jos...@am...> wrote:

> One thing I forgot: have you tested how running agents as plugins in the
> simulator, like the example in rcssserver3d/plugin/soccer/agentintegration,
> improves performance (only for training/learning, not in competitions, of
> course)? Would be interesting to have actual measurements on that.
>
> Cheers,
> Joschka
>
> P.S.: did I mention Bullet integration would be a great project? ;-)
>
> On Feb 19, 2011, at 2:23 PM, Joschka Boedecker wrote:
>
> > Hey Sander,
> >
> > On Feb 19, 2011, at 5:23 AM, Sander van Dijk wrote:
> >
> >> Hello MC,
> >>
> >> As you may know, the RC federation put out a call for proposals for
> projects, among others to work on the competition infrastructure. I sent in
> a proposal together with Ubbo Visser, which got accepted. So now I am with
> Ubbo to work on simspark for 2 months, and I would like to keep you up to
> date with what we're doing.
> >>
> >> The main aim of our project is to make the simulator usable for bulk
> training. One part of that means debugging the simulator and make it faster
> and more stable, the other part is to make some external tools. On the
> second point we are still working out the details, but on the first part I
> did some work:
> >>
> >
> > First of all: great to hear you're working on these things! Congrats to
> you and Ubbo on the accepted project proposal :-) Very exciting!
> >
> >> * Did a lot of profiling, which a.o. showed that the server spent more
> than 10% of the time on dynamic casting alone. This was mostly because of
> continuous searches for nodes in the scene tree. I have put in some caching
> here to alleviate it, reducing the time spent casting to 1%. This extra 10%
> has now gone to ODE. I still have to create some performance tests to see if
> this made stuff faster.
> >
> > Nice :-)
> >
> >>
> >> * Multi threading mode is fixed (but see below). Although at first I was
> doubtful of whether the current way it is done would help, it should,
> because now the second and third most costly things, gathering perception
> data (20%) and gathering monitor data (8%) can now be done in parallel.
> However, while running a 6vs6 game there is not a real noticeable speed-up.
> But again, I still have to do proper performance tests to see what it does.
> >
> > Very cool.
> >
> >>
> >> However, the biggest opportunity to optimise is ODE, which now eats up
> 67-70% of all computation time. There was a project at CMU in 2007 to
> parallelize ODE [1], where they made the collision detection parallel.
> Profiling shows however that this will not help: collision detection takes
> up 0.45% in rcssserver3d. What is expensive for us, is stepping the physics.
> Luckily, ODE already splits this work into different parts, updating
> 'islands' seperately, where in our case each island is one agent. I am now
> working on parallelising this, and if that works we can in theory cut up the
> 67% CPU time into 12/18 parts (4vs6/9vs9) that can be run in parallel,
> hopefully making having 8 cores actually useful.
> >>
> >
> > Long time ago, Hesham Ebrahimi worked on parallelizing parts of ODE as
> team member of the MC. He used the Intel Threading Building Blocks (TBB)
>  library back then, but unfortunately, I'm not exactly sure anymore what
> happened to that code :-( Anyways, I remember that there's a book on Intel
> TBB published by O'Reilly (author is James Reinders) which he used. This has
> parallelization of ODE as an example towards the end of the book. See if you
> can get a hold of that it, it might be a big help (at least that last part
> on ODE).
> >
> > Otherwise, I would suggest considering the integration of the Bullet
> physics engine [1] as an alternative to ODE. Bullet has more features, a
> very active development team, and increasing support for massively parallel
> computation for collision detection and for the solver using OpenCL. This
> looks like the better alternative for the future to me.
> >
> > The project I did with Andreas to move ODE to a plugin and enable other
> physics engines was meant to be the first part for a later Bullet
> integration, but unfortunately, nobody had time to work on that yet. Give
> Bullet integration some thought :-) I don't have any data at hand, but I'm
> pretty convinced it will lead to much better performance, especially when
> supported by GPU computation and multiple CPUs.
> >
> > Keep us updated on your progress and all the best,
> > Joschka
> >
> > [1] http://bulletphysics.org/
> >
> ------------------------------------------------------------------------------
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > _______________________________________________
> > Simspark Generic Physical MAS Simulator
> > simspark-devel mailing list
> > sim...@li...
> > https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>


-- 
Adaptive Systems Research Group
Department of Computer Science
University of Hertfordshire
United Kingdom