Fantastic work. The improvements to the I/O manager are well worth the price of admission.
I'm curious, is work underway to see similar gains made in the I/O manager on Windows?
Does Windows provide a similar construct as 'select()' and also something equivalent to the newer epoll/kqueue systems, such that boosting the I/O manager on Windows will be rather trivial, or is the Windows I/O subsystem so different that the GHC I/O manager must be designed completely differently on that platform?
The Windows operating system presents a difficulty to our current design. Its support for scalable event notification is based around I/O completion ports, which are integrated tightly with the Windows threading mechanism, and which would require a considerable amount of replumbing to support.
Windows provides select just like everybody else. High performance IO in windows is done with IO Completion Ports it is a little more complicated than epoll.
Is there a "Why Haskell?" post somewhere out there? I am just curious about what Haskell brings to the table, what it is good at, and does it have a niche. Is Haskell trying to break its bonds in the niche to get to the wider world in general? All sorts of questions like that.
The big things that Haskell does that no-one[1] else does are a) strict separation of the parts of the program that do I/O or otherwise change some sort of global state and b) lazy evaluation, which means evaluate a function only when it is needed to do (a). The compiler enforces (a).
(a) is a big deal because it makes it very easy to reason about what your program does, which is handy because (b) is the opposite :-) but makes certain kinds of computations very elegant to express.
I'm curious about the general effectiveness of the latest versions of GHC in optimizing single-threaded code. We know of huge gains with the parallelism libraries, but I'm wondering what the consensus is for code that's more inherently sequential.
When you say inliner, are you referring to LLVM's inliner or something closer to the front end? I know LLVM's is pretty aggressive as is -- are you able to get benefits from it?
I'm curious, is work underway to see similar gains made in the I/O manager on Windows?
Does Windows provide a similar construct as 'select()' and also something equivalent to the newer epoll/kqueue systems, such that boosting the I/O manager on Windows will be rather trivial, or is the Windows I/O subsystem so different that the GHC I/O manager must be designed completely differently on that platform?