GHC 7 is out: Haskell 2010 support; LLVM backend; new optimizer ... | Hacker News Reader

GHC 7 is out: Haskell 2010 support; LLVM backend; new optimizer ...

article.gmane.org

158 pointsdons15 comments

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.

From http://www.serpentine.com/bos/files/ghc-event-manager.pdf

We need a Windows user who's willing to drive it. Bryan and I are happy to apply patches but neither of us are Windows developers.

Sadly I too am not a Windows developer. That said, I've never before had such a compelling reason to become one.

I do hope that someone more familiar with Windows takes up the torch.

I would but I can't quite figure out GHC's build process.

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.

Congrats and a big thank you to the team. My favorite language and compiler just got a lot better with this update.

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.

Performance improvements via the new inliner and the LLVM backend should improve straight line code.

Quite separately, runtime and library performance for some kinds of parallel programs is better.

Both sequential and parallel code got better, for different reasons.

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?

GHC's inliner -- which does lots of algebraic transformations of the Haskell code to make it fast.

That all happens before getting shunted off to LLVM, which in turn does a lot of block-level changes (which particularly affect numeric code).

Are there any references that detail the new inliner?

Only tangentially related: how do you use the LLVM bindings on Windows?

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.

[1] Not quite true but close enough

Reply on news.ycombinator.com