Re: [simspark-devel] SimSpark boosting project

[Joschka B. <jos...@am...>]

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