On Mar 31, 2011, at 4:03 PM, dsimcha wrote: > == Quote from Sean Kelly ([email protected])'s article >> On Mar 31, 2011, at 11:48 AM, dsimcha 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. >> It bears mentioning that this has interesting implications for the >> default thread-local storage of statics. All fibers running on a thread >> will currently share the thread's static data. This could be worked >> around by doing TLS manually at the fiber level, but it's a non-trivial >> change. > > Let's assume for the sake of argument that we are otherwise ready to make said > change. What would the performance implications of this be for programs > using TLS > heavily but not using fibers? My gut feeling is that, if this has > considerable > performance implications for non-fiber-using programs, it should be left alone > long-term, or fiber-local storage should be added as a separate entity.
It's more an issue of creating an understandable programming model. If someone is using statics, the result should be the same regardless of whether the code gets a dedicated thread or is multiplexed with other code on one thread. ie. fibers are ideally an implementation detail.
