Re: [Caml-list] comparison with C performance

[Brian Hurt <brian.hurt@qlogic.com>]

>From memory, task switches on the 386 were 300-500 clock cycles.  By the 
time of the pentium, the nominal cost of a task switch was ~50 cycles 
IIRC, but this did not include the costs of the TLB and cache flushs.  
Which raised the question of how much work you did after the TLB 
determining how expensive the task switch was (and does those costs count 
to task switch costs anyways?).  I don't beleive it's been signifigantly 
improved since then.

Task switches can be a performance problem.  This is, at heart, the 
problem with microkernel operating systems.  Done "canonically" you are 
task switching constantly.  Especially back in the day of the 
Torvalds-Tannenbaum debate, the task switch cost ate you alive.  The 
successfull microkernels generally did without memory protection- an 
example here is the Amiga kernel.  Microkernel, granted, but no memory 
protection either.  Several realtime OSs do the same stunt.  Or, in a 
slightly less extreme way, you can just move more stuff into the same 
task, reducing the number of task switches you need to make.  This is the 
choice Microsoft made with NT, when they moved the core graphics routines 
into the kernel with NT4.  I find it humorously that the "microkernel" NT 
has graphics in the kernel, while the "monolithic kernel" Linux keeps 
graphics in a user space application (X).  But by pulling functions into 
the same task space, A) you are losing a number of advantages of 
microkernels (for example, a misbehaving driver can now crash the kernel), 
and B) you are starting to look an awful lot like a monolithic kernel.  
The successfull kernels today are actually hybrids of monolithic and 
microkernel, to one extent or another, at this point.

On the other hand, task switching isn't nearly the cost of I/O- disk or
network- which I would expect to dominate.  That being said, limiting task
switches is not the only plausible optimizations an in-kernel NFS server
could implement.  I haven't investigated this code, but some plausible
explanations include interrupt/signal latency, scheduling advantages, few
address mappings/reverse mappings, etc.

Brian
On Thu, 1 May 2003, Lex Stein wrote:

> 
> My short answer is: No.
> 
> Thanks
> Lex
> 
> > Wouldn't you expect any userspace nfs server to be much slower than the
> > kernel-based implementation due to the overhead of all the extra
> > context-switching?
> >
> > --
> > Miles Egan <miles@caddr.com>
> >
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners