Hello,
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.
factor 13x ?
I was talking about _default_ build which uses ucontext.
OK - ucontext does system calls which are time consuming.
Ok I understand and actually I see several things I already would like to try with Boost.Context. Let's continue... ----------------- Several problems I see: a) (BIG ONE) The shared object link using fcontext crashes! Using boost_1_46_0 Building boost_context: bjam toolset=gcc context-impl=asm architecture=x86 instruction-set=native address-model=64 --with-context variant=release stage Then I compile example link.cpp Run it It crashes! When linking with static libboost_context.a it works... OS: Linux artik-laptop 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 GNU/Linux Compiler: gcc-4.4.5 CPU: Intel(R) Core(TM) i5 CPU M 460 @ 2.53GHz b) Building with fcontext is... Too complicated Options: context-impl=asm architecture=x86 instruction-set=native address-model=64 Why should I specify all these parameters? They should be fully auto-configured. I understand that BBv2 is far from being too friendly and powerful system I still expect that most of parameters should be defined by default otherwise there is no chance that users would be actually able to build it clearly. Other Questions ---------------- 1. Please provide a rationale why not both methods are compiled to same library? Sometimes wouldn't it be better to have option about the type of the method you actually use especially if user may want to have both methods. 2. Why boost::contexts::context is template class? How does it benefit from this? Please provide rationale. Thanks, Artyom