Timeline for Issues with time slicing
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 4, 2012 at 10:40 | comment | added | MSalters | "risc processors have more registers so take longer". It's not that simple by far. There's also a whole instruction pipeline that needs to be flushed. RISC processors have a simpler pipeline. | |
| Sep 3, 2012 at 18:31 | comment | added | gbjbaanb | you'll need to do some locking to see any differences in the real world. Locking makes each thread give up part of its allocated time slice, that's when you really notice the switching. Run perf monitor with the 'context switches per second' counter going. | |
| Sep 2, 2012 at 15:02 | comment | added | user12331 | As given in the above example, I have two parameters, number of threads and number of iterations. If for the first case I take 2 threads and 10000000 iterations. For the second case I will take 10 threads and 2000000 iterations. For the third case I will take 100 threads and 200000. So I was expecting the 100 thread version to be a bit slow. But it is at time even faster than the 2 thread version. | |
| Sep 2, 2012 at 15:00 | comment | added | user12331 | Actually, 2 threads is fine. I have a 2 core CPU so they can run parallely. However, if I use 10 or 100 threads to do 1/10 or 1/100 work by each thread, then due to time slicing I should see some slowing down. But I don't see anything. The 10 or 100 thread versions are rarely slow than the 2 thread version. | |
| Sep 2, 2012 at 13:17 | history | answered | gbjbaanb | CC BY-SA 3.0 |