Menu
▾
▴
Re: [simspark-devel] performance
|
From: Hedayat V. <hed...@ai...> - 2008-01-29 20:01:29
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi Hesham,<br>
Thanks for your answer. I'm agree with you about experimenting with a
multi-threaded ODE. In fact, I searched for a multi-threaded ode and I
found a paper but no code (but it was not what you mentioned). I will
search more and I hope that we can find it.<br>
I'll try to download the pdf and will notify you if I can't get it.
Thanks.<br>
Also, I'll try the google profiler too. <br>
<br>
Have a nice time,<br>
Hedayat<br>
<span><br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Hesham
<a class="moz-txt-link-rfc2396E" href="mailto:hes...@gm..."><hes...@gm...></a></b></i> wrote on 01/28/2008 01:08:32
AM:</span><br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:1d7...@ma..." type="cite"><br>
Hi Hedayat and Yuan,<br>
<br>
Hedayat, sorry I didn't find time to reply your email earlier.
Regarding that interface for the physics engines, it sounds a good idea
to either use it directly or write something like that for the server.
But apparently it's a good idea to first test the server with
multi-threaded ODE. I was reading Intel Threading Building Blocks book,
you can find the first chapter at: <a moz-do-not-send="true" href="http://softwarecommunity.intel.com/isn/downloads/intel_tbb_ch01_for_promo.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://softwarecommunity.intel.com/isn/downloads/intel_tbb_ch01_for_promo.pdf</a><br>
In chapter 11 they explain two methods and mention the complete code is
on the website, I tried to find it but so far no luck. (If you don't
have access to the book, let me know I can send you that section.)<br>
<br>
I'm using the Google profiler(/sampler), it's pretty straightforwards.
I tried to write about it on the wiki but it asked me to login, and
using my sorceforge ID/password it failed. Anyway I'll write it within
this week and email it to you, so we can use the same method. And to me
it makes sense that we get different results(/hot spots), because of
different systems (HW&SW) we use. As far as I know a good example
is ATLAS (<a moz-do-not-send="true" href="http://math-atlas.sf.net">math-atlas.sf.net</a>),
using scripts generates the optimized code for different systems.<br>
<br>
Next weekend I'll try to work more on these issues, and probably until
then will know the answer of your 4th question.<br>
<br>
Yuan, the code of <span>SDL_GetTicks() is simple, it doesn't give any
more precision. I didn't get some parts of what you said. Maybe a silly
question but, the server is supposed to have sharp 20ms cycles? I
thought the previous timing method (SPADES) was replaced by the new one
to get rid of the problems we had with timers, and more rely on time
stamps. But you suggested using RTL to have more precise timers. Sorry
maybe I got the whole thing wrong, I'll go through the code again. But
I would appreciate it if you (or others) could please remind me the new
idea for timing, maybe by referring to old emails - I couldn't find
them.<br>
<br>
Thanks,<br>
Hesham<br>
</span><br>
<div><span class="gmail_quote">On 27/01/2008, <b class="gmail_sendername">Hedayat Vatankhah</b> <<a moz-do-not-send="true" href="mailto:hed...@ai..." target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">hed...@ai...</a>>
wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="direction: ltr;" bgcolor="#ffffff" text="#000000"><span>Hi,<br>
First, I think that the loop isn't a problem too. And I wonder if
SDL_GetTicks() creates any major problem now.<br>
But the multi-threaded ODE might be really helpful. <br>
<br>
Second, would you please how do you profile the server? Each of us gets
different results and I wonder why is so. Also, for the profiling
results I provided in my previous mail I used valgrind's tools. As it
is really slow, I used just one robot in those tests. Please tell me
about the ways you use for profiling the server.<br>
<br>
Finally, It would be really nice if you tell me your opinions or the
mistakes in the patch I sent with my email recently(in the email with
subject: "some experiments with the server"). Also, I'm really
interested to know about the answer of the 4th question.<br>
<br>
Thanks anyway,<br>
Hedayat<br>
<br>
<i><b>"Yuan
Xu" <a moz-do-not-send="true" href="mailto:xuy...@gm..." target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"><xuy...@gm...></a></b></i>
wrote on 01/27/2008 06:01:45 PM:</span>
<div><span><br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" type="cite">
<pre>Hi Hesham and all,
</pre>
<blockquote type="cite">
<pre>After profiling the server I saw SDL_GetTicks() is taking around 25% of the
time (in the tests I used 7 robots and with the single thread mode). To make
long short, I saw this loop (while) in simulationserver.cpp:
....
Since SimulationServer::Step() takes care of this case
(int(mSumDeltaTime*100) < int(mSimStep*100)) I thought that while in Run()
is not necessary. So after commenting it out, SDL_GetTicks() takes less than
10% of the time:
</pre>
</blockquote>
<pre>The phenomenon is reasonable.
Since the time queries are needed for timing in single thread,
the percentage of queries means that your machine are light underload(
not too busy ),
I guess your robots did not do anything. You will notice that the
percentage of queries will lower if robots are collides...
But if you remove the codes, the timer is noneffective. Then if the
robots collides, the server will very very slow, otherwise the
simulation time elapse very quickly.
You may ask why use query to get time, ok, I do not think it is a good idea.
The server cycle is 20ms, but the time precision of Linux is only 10ms,
some function such as "sleep" also can not help on it.
In fact, SDL_GetTicks() is used to get "preciser"(seemly).
And it is possibly that SDL causes the Input problem in multi-threads.
I have some idea to this:
1. to get precise time, use RealTime-Linux as platform [It will
narrow OS platform]
2. use a new thread to time, The timing is in InputControl thread in
current multi-thread implementation, but query is also used(It can be
improved little). [It may make the timing-thread busy, and can not
guarantee precision.]
3. use other timer instead SDLTimer, such as boost::xtime. [It need
more investigation.]
</pre>
<blockquote type="cite">
<pre>BTW, the other day I came across the multi-threaded version of ODE by Intel.
</pre>
</blockquote>
<pre>Sounds interesting.
</pre>
</blockquote>
<br>
</span></div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
