If we could make the libuv backend optional and keep the existing codepath then maybe I can see us merge this, but otherwise it seems like we should simply try to optimize what we have rather than throw the whole
#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 have attached the heap profile, the previous `+RTS -s` seems to be a mistake(I don't have a clue why it report such a big different), mio do allocate more memory, but that much. The benchmark parameters are: {{{wrk -c1000 -d10s http://127.0.0.1:8888}}} The request rate are {{{ libuv: Requests/sec: 264542.07 mio: Requests/sec: 236880.75 }}} thing away. I personally feel no rush to change current base's I/O manager: it works well, and needed by GHCi. But since this ticket's purpose is to discuss the possibilities of integrate libuv, i would like to hear more.
native dependencies are bound to either increase the complexity of the build system (if we statically link) or dramatically complicate distribution (if we dynamically link).
I'm interested in distribute my library with a statically linked libuv, is it possible with cabal? libuv is quite easy to build on unix, but i don't know the situation on windows, it seems require visual studio.
Further, it looks like libuv doesn't even support all of the platforms which GHC supports (OpenBSD, for instance).
This is definitely not true, Node.js officially support OpenBSD so i don't see a reason why libuv not. I guess OpenBSD is just not on their CI.
I strongly suspect there is some very low-hanging fruit in mio.
Can't say for libuv branch, but I think i got some other low-hanging fruit, e.g. i'm preparing the patch for `primitive` since you asked. It will include the `PrimArray a` and `class Arr (marr :: * -> * -> *) (arr :: * -> * ) a | arr -> marr, marr -> arr`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler