multi-core software

[Jeff M.]

On Jun 7, 1:56 am, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> "Jeff M." <mass... at gmail.com> writes:
> > > > Even the lightest weight
> > > > user space ("green") threads need a few hundred instructions, minimum,
> > > > 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.