On 11.05.2011, at 19:48, kxng wrote: > Here are the results I ran your sample program on one core and dualcore > machines: > > One Core: > run with Update Less: Worker0: on average takes 3750 miliseconds > Worker0 + Worker1: on average takes 5980 ms > > Dual Core: > run with Update Less: Worker0: on average takes 4000 ms > Worker0 + Worker1: on average takes 7532 ms. > > I looked at the task manager performance when running on dualcore, the two > cores were not processing simultaneously. > > I would like to take the advantage of the dualcore. What is the approach I > should take to program one core doing calculation while the other core > displaying results? >
Yes, because your "test_thread" calls "display_value" all the time (tens of thousands of times a second). On a single core machine, everything runs nicely serialized: your thread goes into lock state, sends and awake, unlocks, then right away locks again. That will switch your single core back to the first task that no immediately runs whatever "awake" kicked of, unlocks, and waits. This will unlock the thread which will then continue again right away. You basically generated two (or three) gears that mesh perfectly in a sequential order. But if you run on a dual core, locks and unlocks will be fired at the same time from three independent threads, causing lots of waits for other locks. Since your "busy loops" are pretty much only lock, unlock, and awake functions, the dual core overhead eats up all advantages and more. Now you have three gears that run at different speeds, trying to get a useful order of execution. Now what is the solution? Multithreading is great if you have lengthy calculations, or parallel calculations on different datasets. In the first case, you try to avoid lock and unlock as much as possible. I try to call lock() at most 20 times a second when I need to tell the app that it needs to redraw the GUI. In the second case, the FLTK locking mechanism is simply not useful. There are much better ways of synchronizing threads on every OS. After all calculations are synched and data needs to be displayed, Fl::lock()/unlock()/awake() is fine again... . Matthias _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
