Menu
▾
▴
Re: [simspark-devel] SimSpark boosting project
|
From: Hedayat V. <hed...@gm...> - 2011-02-20 08:28:56
|
<!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,<br>
<br>
On ۱۱/۰۲/۲۰ 09:06, Sander van Dijk wrote:
<blockquote
cite="mid:AAN...@ma..."
type="cite">....
<div class="gmail_quote">
<div><br>
</div>
<div>Yes, good point. I will make sure to record all test
details. For now: I am mostly using valgrind (with the
callgrind and helgrind tools in specific). I first tried
gprof, but then everything was very unstable, but maybe that's
helped with the current fixes.</div>
</div>
</blockquote>
Thanks.<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">...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.</div>
</blockquote>
<div><br>
</div>
<div>Yes, Andreas notified me of that, too. This happens when
agents and server are run on the same machine with multiple
cores.I have found that at some point, the system's scheduler
assigns an agent to the same core as the server (even though
in practice there is still room on another core), so the
server can't run at full speed. With taskset(1) it is possible
to explicitly set a process' CPU affinity, and by starting the
agents with e.g. 'taskset 2 ./start.sh localhost' the server
is able to take up 100% again.</div>
</div>
</blockquote>
Great, thanks for the info. We might be able to design a more
general framework for running agents using Linux CGroups and maybe
taking advantage of perf tools. But I should investigate more before
being able to comment more on this issue.<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">...<br>
</blockquote>
</div>
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>
</div>
</blockquote>
<div><br>
</div>
<div>From what I can tell so far it seems that the main part of
the speed reduction due to collisions is not caused by the
collision detection, but by the fact that it adds many new
constraints to the LCP problem that ODE solves to step the
physics. However, I still have to make a team of robots that
just run into each other to be able to say that with
certainty. And you are right, it would be nice in any case ;)
<br>
</div>
</div>
</blockquote>
Thanks for the clarification. Yes IIRC solving the LCP problem was a
real bottleneck. If it doesn't worth the effort, we might skip this
part for now. <br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">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>
</div>
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>
</div>
</blockquote>
<div><br>
</div>
<div>I think you refer to:</div>
<div>
<div><br>
</div>
<div> if (isInputControl)</div>
<div> {</div>
<div> while (int(mSumDeltaTime*100) <
int(mSimStep*100))</div>
<div> controlNode->StartCycle(); //
advance the time</div>
<div> }</div>
</div>
<div><br>
</div>
<div>? The only use I saw of that was to keep updating the
InputControl to get messages from the monitor while the
physics are updated. The time check is there to stop doing
this when the physics are done. Without this check, the
InputControl (and the other controls, AgentControl and
MonitorControl) wait for the physics to be done anyway at the
next barrier, so the cycle can't be finished too soon. And
this loop caused the most problems with multi threading,
because it allowed the scene graph to be changed while the
physics were still running on it.</div>
</div>
</blockquote>
Yes, I was referring to this loop. Unfortunately InputControl
doesn't exactly do what it is supposed to. Beside handing input, it
also functions as the simulator timer, which is very ambiguous (and
I'm going to replace it with another timer implementation). This
loop is not intended to receive messages from the monitor (you'll
see the same loop in SimulationServer::Cycle() which is run in
single threaded mode); it is a busy-waiting loop to make sure that a
cycle will not last less than mSimStep. On of the functions which
InputControl::StartCycle does is to inspect SDL's timer and call
SimulationServer::AdvanceTime(), which in turn updates
mSumDeltaTime. Yes, doesn't look good and was really problematic for
me to understand what happens completely :P<br>
<br>
Personally, I'm planning to remove the use of SDL timer altogether
and switch to using Boost's timing facilities, which is much more
cleaner and also doesn't need a busy-waiting loop. <br>
<br>
Thanks,<br>
Hedayat<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> <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>
</div>
</blockquote>
<div><br>
</div>
<div>Looking forward to it :)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> <br>
Thanks,<br>
<font color="#888888"> Hedayat</font><br>
</div>
</blockquote>
</div>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</blockquote>
</body>
</html>
|
