From: Hesham <hes...@gm...> - 2008-01-27 21:38:37
|
Hi Hedayat and Yuan, 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: http://softwarecommunity.intel.com/isn/downloads/intel_tbb_ch01_for_promo.pdf 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.) 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 (math-atlas.sf.net), using scripts generates the optimized code for different systems. Next weekend I'll try to work more on these issues, and probably until then will know the answer of your 4th question. Yuan, the code of 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. Thanks, Hesham On 27/01/2008, Hedayat Vatankhah <hed...@ai...> wrote: > > Hi, > First, I think that the loop isn't a problem too. And I wonder if > SDL_GetTicks() creates any major problem now. > But the multi-threaded ODE might be really helpful. > > 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. > > 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. > > Thanks anyway, > Hedayat > > *"Yuan Xu" <xuy...@gm...> <xuy...@gm...>* wrote on > 01/27/2008 06:01:45 PM: > > Hi Hesham and all, > > > 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: > > 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.] > > BTW, the other day I came across the multi-threaded version of ODE by Intel. > > Sounds interesting. > > > |