#8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I share the same concerns above, so my experiment is still under going, so far the results are: the libuv I/O system's performance is slightly better(~10%), and allocate slightly less(~10%~20%), the GC pause is much lower(~30%). we test it under different load, we also did a test on a 36-core 512G RAM server accorading to the MIO paper. We(I and a student in BHU who used to work as an intern under my supervision) are planning to write a paper about this new I/O system design, collecting all the result above, and do some analysis. Since this year's HIW submission is closed already. We're looking forward to submit this paper in next year's HIW. So we still have plenty of time to polish our work. We would much appreciate if someone can recommend some places to submit a paper like this ; ) If we somehow choose to use libuv in GHC, the libuv dependency should be managed like libffi IMO, it's easy to build and we should ship it with GHC to help user get started(just like node.js). As for correctness, i think switch to libuv is actually helpful to reduce bugs since we don't need to interface different OS event backend. A regression test suite is definitely helpful, i'll try to make one. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler