On 31/03/11 20.48, dsimcha wrote:
== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
Are fibers really better/faster than threads? I've heard rumors that
they perform exactly the same, and that there's no benefit of using
fibers over threads. Is that true?
Here are some key differences between fibers (as currently implemented in
core.thread; I have no idea how this applies to the general case in other
languages) and threads:
1. Fibers can't be used to implement parallelism. If you have N> 1 fibers
running on one hardware thread, your code will only use a single core.
The fastest webservers out there (e.g. zeus, nginx, lighttpd) also use
some kind of fibers and they solve this problem by simply forking the
process and sharing the listening socket between processes. That way you
get the best of two worlds.
/Jonas
2. Fibers use cooperative concurrency, threads use preemptive concurrency.
This
means three things:
a. It's the programmer's responsibility to determine how execution time is
split between a group of fibers, not the OS's.
b. If one fiber goes into an endless loop, all fibers executing on that
thread will hang.
c. Getting concurrency issues right is easier, since fibers can't be
implicitly pre-empted by other fibers in the middle of some operation. All
context switches are explicit, and as mentioned there is no true parallelism.
3. Fibers are implemented in userland, and context switches are a lot cheaper
(IIRC an order of magnitude or more, on the order of 100 clock cycles for fibers
vs. 1000 for OS threads).
