Menu
▾
▴
Re: [simspark-devel] SimSpark boosting project
|
From: Hedayat V. <hed...@gm...> - 2011-02-20 00:35:34
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Sander!<br>
(my reply with more time to write! :P)<br>
<br>
On ۱۱/۰۲/۱۸ 11:53, Sander van Dijk wrote:
<blockquote
cite="mid:AAN...@ma..."
type="cite">Hello MC,<br>
<br>
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.<br>
</blockquote>
Thanks for letting us informed, and very happy to hear that it is
going to happen in these 2 months. :)<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
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:<br>
<br>
* 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.<br>
</blockquote>
That's great. It'd be also nice if you specify which tools do you
use for profiling for the record. IIRC, previously we had some
inconsistent profiling results based on the tools we used; so it
might be helpful to know the tools beside the results. Also, it
might be helpful if you provide the complete results about the most
time consuming parts with more details. Maybe there are people
who'll work on some other time consuming parts. :)<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
* 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.<br>
</blockquote>
Thanks for the fix. <br>
We've not conducted any benchmarks to find the difference when
multi-threading is enabled and when it is disabled; but our
experience at IranOpen 2010 and apparently GermanOpen 2010
experience have shown that multi-threaded mode is practically
faster.<br>
Also, Andreas Seekircher has reported his experience with
multi-threaded which also confirms that multi-threaded mode is
faster, but also he has faced a problem which deserves some
attention:<br>
<blockquote type="cite">However there was a strange behavior, that
the simulation was running quite fast on my laptop with up to 9
agents and the simulator was using more than one core. When I
started the 10th agent it was getting much slower and it seemed
that the simulator was then using only one core (it was then again
the same speed like without multi-threading). This happened with 4
cores. On a dual core system already the 5th agent slowed down the
simulation... Is this a known issue?
</blockquote>
I guess that in this situation, ODE is the main bottleneck. But
that's just a guess.<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
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.<br>
</blockquote>
Great. But it'd be probably nice if we parallelize the collision
detection too. Specially, it's computation time will increase
considerably when two or more robots collide (fortunately the new
referee doesn't allow many robots to collide at the same place, but
with more players it is more likely that we'll have collisions in
different part of the field). <br>
<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
So far about what I am doing. Now, I would also like something
from you guys ;-) First of all, give the new stuff I committed a
good test. Behaviour of the simulator should still be the same,
but it could be that I missed something and that timing of
messages is slightly different, breaking agents. Also, give the
multi threaded mode a good test, see if you can make it crash.
And, finally, I will be working full time on the simulator for 1
1/2 months more, if you think there is anything that I may be able
to squeeze in there, do let me know!<br>
</blockquote>
Certainly! :) <br>
I noticed something in your recent commit: you've removed the ugly
busy-waiting loop in SimControlThread, but wouldn't it result in a
faster simulation when ODE has not much work to do? The loop was
there to make sure that a cycle will last no less than 0.02
(mSimStep). If I'm not mistaken, it is now possible for a cycle to
finish too soon. <br>
<br>
There are some collaboration opportunities with your work and what
I'm planning to do, but I'll talk about them in a separate email
soon.<br>
<br>
Thanks,<br>
Hedayat<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
Cheers,<br>
Sander<br>
<br>
[1] <a moz-do-not-send="true"
href="http://www.cs.cmu.edu/%7Empa/ode/">http://www.cs.cmu.edu/~mpa/ode/</a><br>
<br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
<br>
</blockquote>
</body>
</html>
|
