Code center > Bug reports
Working on 2.42.0
Numsgil:
I'm a compuer science person and that just bleew my mind :D
Maybe we should measure our computers in FLOPS.
EricL:
--- Quote ---DB should be a program that could parallel quite well, but I have no idea if the code is set up right for it.
--- End quote ---
It's not. There are only two threads in the process and one does all the work. This is easy to see. Run perfmon.exe from a command line and add the % processor counters for DB from the Thread object.
Multi-threading it will take some work to make it thread safe. Non trivial, but not rocket science.
-E
Numsgil:
The C++ code is multithreaded, but only between the GUI and the Engine.
EricL:
I bet we could get a lot of bang for the buck by doing corse grain threading in just a few key places in the engine, like anywhere there is a loop that cycles through the rob array. Spin 10 threads, do 10 robots at a time in parallel. Just given the nature of the beast(s) (pun intended) I think a lot of the loops like this are already relatively parallizable, with few or no critical sections needing protection though we would want to take a very careful walk through anything we thread to make sure. Trying to find multi-threaded timing bugs can drive you crazy - they tend not to repro when you want them to. Much better to not introduce them in the first place...
Even the simplest profile run will tell us which routines are the key ones to focus on for both threading and algorithm improvement. Sigh. One more thing to add to the to do list....
-E
Numsgil:
I usually do profile the code from time to time. I like to use Intel's VTune even if it is way overpowered for my needs.
I think you're right about setting up different threads for the robot loops. I'll start working on it when I get passed the implementation and debugging stage.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version