Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

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?

share|improve this question

2 Answers

up vote 1 down vote

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)

share|improve this answer
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 Sep 2 '12 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 Sep 2 '12 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 Sep 3 '12 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 Sep 4 '12 at 10:40
up vote 0 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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