Re: [boost] [context review] Several Questions

Subject: Re: [boost] [context review] Several Questions
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-03-21 08:43:33

> > There were two threads giving  each one a time quanta and measured
> > how much time context switch takes  (of course included some warm up)
> > 
> > sched_yeild  -  377us
> > Boost.Contex - 214us
> > Dummy        -  10us
> > 
> > All tests done on a single CPU using taskset 0x1 ./test  params
> > 
> > So finally I can see that Boost.Context does not behave  **much** 
> > better then OS context switch?
> 
> Hmm - did you see the  performance measuring test coming with the lib 
>(libs/context/performace)?
> It  counts the CPU cycles taken by a switch. The tool was used to compare 
>ucontext_t
> (which does some system calls for preserving the signal mask) and 
> fcontext_t  (which doesn't perserve the signal mask and is which is
> implemented in  assembler).
> 
> I modified it and I measured following (AMD Athlon(tm) 64 X2  Dual Core 
>Processor 4400+):
> 
> cmd: performace -s -i  100
> 
> sched_yield(): 2108 cycles
> ucontext_t:    1795  cycles
> fcontext_t:     156 cycles
> 

Actually it is quite consistent with what you had show,
the Boost.Context is better (but not significantly) then
real OS (kernel) context switch.

>
> Maybe you can send me your  test code?
>

I'll send it later (no access to that PC now)

> 
> > Usefulness of N:M model (or even 1:M model)
> >  -------------------------------------------
> > 
> 
> Indeed the OS develoeprs moved from N:M to 1:1 (so as Solaris  did) 
> and the N:M paradigm may not usefull for OS but may for user-land  apps.
> 
> But I use it for instance in boost.task to allow a task create and  wait
> on sub-tasks using boost.context. This allows work-stealing by other  
>worker-threads.
> 

It would be very useful to see real usability cases. Because otherwise
it is hard to estimate usefulness of this library

> In general it is usable in all cases where the code may  want to jump to 
>another
> execution path but wants to come back and have all local  data preserved in 
>order
> to continue its work.

I understand, it may be useful for "yeild" like iterators and so
but it is not clear how does it work and what is the advantage
in comparison to ordinary event driven approach.

Regards
  Artyom