That depends on your OS ;-). Linux tries to make process context switches extremely cheap (and as a result you can get away with using processes instead of threads for parallel performance). This recent mail on LKML states that on a 3GHz P4 the 2.6 kernel can do up to 700,000 process context switches per second. That's only if the processes do nothing except switch, the mail goes on to explain that under normal workloads you'd only get about 10,000 switches per second.

I just ran the following script:

#!perl -slw
use strict;
use threads;

sub thread{
        Win32::Sleep 0 while 1;
}

my @threads = map{ threads->create( \&thread ) } 1 .. 100;

<STDIN>;
[download]

Which sets 100 threads going that do nothing but relinquish the processor in a tight loop. With a single copy of this running, I get sustained measurements of 320,000 context switches/second with occasional peaks of up to 345,000.

However, if I set a second copy of the script running concurrently, so that roughly 1 in 2 context switches will be a process swap as well as thread switch, the numbers drop to a sustained average of around 215,000/s which clearly shows the extra cost of switching processes (on my OS:). It would be interesting to see the numbers you get for a linux system. Do you run a threaded Perl?

However, you do not have to do very much at all to drop these figures way down. Calling gettimeofday() on each thread slows this to around 90,000/second for one copy of the 100 thread process, with a second copy of the script bringing it down to 80,000 or so, and each subsequent process causing a similar drop.

#!perl -slw
use strict;
use threads;
use Time::HiRes qw[ gettimeofday ];

sub thread{
    my( $s, $u );
    while( 1 ){
        Win32::Sleep 0;
        ( $s, $u ) = gettimeofday();
    }
}

my @threads = map{ threads->create( \&thread ) } 1 .. 100;

<STDIN>;
[download]

Of course, do any form of IO, or anything that semaphores (like shared variable accesses) and the number drops like a stone.

So, at least from this practical test it appears you are right, processes don't switch quickly enough for Time::HiRes to return the same result.

No, but it would appear possible for it to happen from within the same process--under Linux and 5.6.2 at least. See the subthread starting at Re^2: OT How fast a cpu to overwhelm Time::HiRes.

I couldn't get anywhere near it on my system, but the need to convert between Win32 APIs and the returns dictated by the gettimeofday() call have a significant impact. Even going direct to the high performance timer from C, I couldn't get any closer than just over 1 microsecond elapsed.