On Thu, 31 Mar 2011 14:48:13 -0400, dsimcha <[email protected]> wrote:
== Quote from Andrej Mitrovic ([email protected])'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.
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).
4. often there is an OS limit on how many threads a process can create.
There is no such limit on fibers (only memory). Using fibers can increase
the number of simultaneous tasks that can be run by quite a bit.
-Steve
