From: Hedayat V. <hed...@ai...> - 2008-01-14 20:05:35
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html style="direction: ltr;"> <head> </head> <body style="direction: ltr;" bgcolor="#ffffff" text="#000000"> <p style="margin-bottom: 0cm; margin-top: 0pt;">Hi all,</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Today, I have played with the server a bit, and these are the results (might be useful!);</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">1) I did a test with dWorldQuickStep() instead of dWorldStep(). With the default iterations, players would explode. I tried with 100 and 1000 iterations, the robots didn't explode but they did some strange behaviors. I think that it is not useful, at least with the current parameters. </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">2) I did what Joschka said about the Space creation. It seems reasonable so it is included in the patch I've attached to this mail. However, I didn't notice any improvements. (Not an accurate comparison, just some observations.)</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">3) I was unable to run the server in the multi-threaded mode (it crashed), and I decided to have a look at code. I decided to rewrite some parts of it and I used a barrier object instead of using condition variables. I think the code is a little simpler now and might be a little faster too. The code is attached to this mail. It seems that the EndCycle functions are not thread safe and also, when the EndCycle function of the RenderControl is called outside the main thread it crashed on the first gl function call (at least in my system). I implemented this (treating RenderControl as an exception) and it didn't crashed like before, but after some time it crashed in the middle of one of EndCycle functions which shows that the EndCycle functions are not thread safe. For now, I removed that exception and I simply call EndCycle functions in the main thread. It might be possible to improve things a little by moving some of the functionality of EndCycle function into the surprisingly unused SenseAgent/ActAgent functions!</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Finally, I'm still unable to use an external monitor in multi-threaded mode. So currently I run the external monitor in single threaded mode. I didn't investigate it.<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">4) What's the reason for stepping in discreet steps in SimulationServer::Step()? I think that it wouldn't change anything for GameControlServer, but what about the scene server?! Will it change anything with ODE?</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">5) As reported in sserver mailing list, simulation is more stable with ODE 9.0, but much performance improvement is needed. On my system (AMD 3000+) with 6 agents, each simulation step (using non-discreet steps) needs around 0.04s.</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">6) I ran a profiling test of the server right now, and it seems that (well, it was my first experience with callgrind!) dWorldStep is really a bottleneck. It might be related to the current robot model...<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Good luck,</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Hedayat<br> </p> </body> </html> |