2

I was trying to see the effect of time slicing, and how it can consume significant amount of time. Actually, I was trying to divide a certain task into a number of threads and see the effect.

I have a two core processor. So two threads can run in parallel. I was trying to see if I have a task w that is done by 2 threads, and if I have the same task executed by t threads with each thread doing w/t of the task. How much does time slicing play a role in it.

As time slicing is time consuming process, I was expecting that when I do the same task using a two thread process or by a t thread process, the amount of time taken by the t thread process will be more.

Any suggestions?

Improve this question
0

2 Answers 2

Reset to default
1

time slicing is a small cost - each time the thread quantum expires and the scheduler switches to another thread, all the registers have to be saved and the new thread's old state restored. If you do this continually, you will see this context switching take a lot of the overall time, but if you have 2 threads running on 2 CPUs, you're not going to see any switching at all. How long exactly does a context switch take? depends on the CPU - risc processors have more registers so take longer. How long is a thread quanta? depends on the OS.

The other cost is in CPU cache invalidation - if 2 threads are running on the same CPU, and each one is working of different data, then the required data will have to re-fetched which will slow things down tremendously on modern CPUs (you won't see this effect so much on older CPUs)

Improve this answer
4
  • 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.
    – user12331
    Commented Sep 2, 2012 at 15:00
  • 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.
    – user12331
    Commented Sep 2, 2012 at 15:02
  • 1
    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.
    – gbjbaanb
    Commented Sep 3, 2012 at 18:31
  • "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.
    – MSalters
    Commented Sep 4, 2012 at 10:40
0

http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html

The article above tries several ways to measure context switch time for a number of recent processors.

It comes up with a rough 30 microseconds (good worst case) per context switch though the numbers vary a lot depending on what you are measuring.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.