Re: multi-core software
On Jun 7, 1:56 am, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
"Jeff M." <mass...@gmail.com> writes:
Even the lightest weight
user space ("green") threads need a few hundred instructions, minim=
um,
to amortize the cost of context switching....
There's always a context switch. It's just whether or not you are
switching in/out a virtual stack and registers for the context or the
hardware stack/registers.
I don't see the hundreds of instructions in that case.
http://shootout.alioth.debian.org/u32q/benchmark.php?test=threadring&..=
..
shows GHC doing 50 million lightweight thread switches in 8.47
seconds, passing a token around a thread ring. Almost all of that is
probably spent acquiring and releasing the token's lock as the token
is passed from one thread to another. That simply doesn't leave time
for hundreds of instructions per switch.
Who said there has to be? Sample code below (just to get the point
across):
struct context {
vir_reg pc, sp, bp, ... ;
object* stack;
// ...
context* next;
};
struct vm {
context* active_context;
};
void switch_context(vm* v)
{
// maybe GC v->active_context before switching
v->active_context = v->active_context->next;
}
Also, there isn't "hundreds of instructions" with multiplexing,
either. It's all done in hardware. Take a look at the disassembly for
any application: one that uses native threads on a platform that
supports preemption. You won't see any instructions anywhere in the
program that perform a context switch. If you did that would be
absolutely horrible. Imagine if the compiler did something like this:
while(1)
{
// whatever
}
do_context_switch_here();
That would suck. ;-)
That's not to imply that there isn't a cost; there's always a cost.
The example above just goes to show that for green threads, the cost
[of the switch] can be reduced down to a single pointer assignment.
Jeff M.