== Quote from Sean Kelly (s...@invisibleduck.org)'s article > On Mar 31, 2011, at 4:03 PM, dsimcha wrote: > > == Quote from Sean Kelly (s...@invisibleduck.org)'s article > >> On Mar 31, 2011, at 11:48 AM, 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. > >> 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.
Yes, but what would be the likely performance cost of doing so?
