|
# GHC status April 2010
|
|
# GHC status April 2010
|
|
|
|
|
|
## GHC 6.12
|
|
|
|
|
|
|
|
|
|
|
|
In the past 6 months we have made the first 2 releases from the 6.12 branch. 6.12.1 came out in December, while 6.12.2 was released in April. The 6.12.2 release fixes many bugs relative to 6.12.1, including closing 81 trac tickets. For full release notes, and to download it, see the GHC webpage ([http://www.haskell.org/ghc/download_ghc_6_12_2.html](http://www.haskell.org/ghc/download_ghc_6_12_2.html)). We plan to do one more release from this branch before creating a new 6.14 stable branch.
|
|
In the past 6 months we have made the first 2 releases from the 6.12 branch. 6.12.1 came out in December, while 6.12.2 was released in April. The 6.12.2 release fixes many bugs relative to 6.12.1, including closing 81 trac tickets. For full release notes, and to download it, see the GHC webpage ([http://www.haskell.org/ghc/download_ghc_6_12_2.html](http://www.haskell.org/ghc/download_ghc_6_12_2.html)). We plan to do one more release from this branch before creating a new 6.14 stable branch.
|
|
|
|
|
... | @@ -18,14 +16,13 @@ Meanwhile, in the HEAD, the last 6 months have seen more than 1000 patches pushe |
... | @@ -18,14 +16,13 @@ Meanwhile, in the HEAD, the last 6 months have seen more than 1000 patches pushe |
|
### Language changes
|
|
### Language changes
|
|
|
|
|
|
|
|
|
|
We have made a few small language improvements.
|
|
We have made only a few small language improvements.
|
|
|
|
The most significant ones concern quasi-quotations, implementing
|
|
|
|
suggestions from Kathleen Fisher:
|
|
Kathleen Fisher suggested two improvements to quasi-quotation:
|
|
|
|
|
|
|
|
- Quasi-quotes can now appear as a top-level declaration, or in a type, as well
|
|
- Quasi-quotes can now appear as a top-level declaration, or in a type, as well
|
|
as in a pattern or expression.
|
|
as in a pattern or expression.
|
|
- Quasi-quotes have a less noisy syntax.
|
|
- Quasi-quotes have a less noisy syntax (no "$").
|
|
|
|
|
|
|
|
|
|
Here's an example that illustrates both:
|
|
Here's an example that illustrates both:
|
... | @@ -36,7 +33,7 @@ f x = x+1 |
... | @@ -36,7 +33,7 @@ f x = x+1 |
|
```
|
|
```
|
|
|
|
|
|
|
|
|
|
The second delaration uses the quasi-quoter called `pads` (which must
|
|
The second declaration uses the quasi-quoter called `pads` (which must
|
|
be in scope) to parse the "...blah..blah..", and return a list of
|
|
be in scope) to parse the "...blah..blah..", and return a list of
|
|
Template Haskell declarations, which are then spliced into the program
|
|
Template Haskell declarations, which are then spliced into the program
|
|
in place of the quote.
|
|
in place of the quote.
|
... | @@ -48,16 +45,16 @@ Type families remain the the hottest bit of GHC's type system. Simon |
... | @@ -48,16 +45,16 @@ Type families remain the the hottest bit of GHC's type system. Simon |
|
PJ has been advertising for some months that he intends to completely
|
|
PJ has been advertising for some months that he intends to completely
|
|
rewrite the constraint solver, which forms the heart of the type
|
|
rewrite the constraint solver, which forms the heart of the type
|
|
inference engine, and that remains the plan although he is being slow
|
|
inference engine, and that remains the plan although he is being slow
|
|
about it. (The existing constraint solver works surprisingly
|
|
about it. The existing constraint solver works surprisingly
|
|
well, but we have lots of tickets demonstrating bugs in corner cases.)
|
|
well, but we have lots of tickets demonstrating bugs in corner cases.
|
|
An upcoming epic (60-page) JFP paper brings together all the key ideas;
|
|
An upcoming epic (70-page) JFP paper "Modular type inference with local assumptions"
|
|
watch Simon's home page.
|
|
brings together all the key ideas; watch Simon's home page.
|
|
|
|
|
|
### The mighty simplifier
|
|
### The mighty simplifier
|
|
|
|
|
|
|
|
|
|
One of GHC's most crucial optimisers is the Simplifier, which is
|
|
One of GHC's most crucial optimisers is the Simplifier, which is
|
|
reponsible for many local transformations, plus applying inlining and
|
|
responsible for many local transformations, plus applying inlining and
|
|
rewrite-rules. Over time it had become apparent that the
|
|
rewrite-rules. Over time it had become apparent that the
|
|
implementation of INLINE pragmas wasn't very robust: small changes in
|
|
implementation of INLINE pragmas wasn't very robust: small changes in
|
|
the source code, or small wibbles in earlier optimisations, could mean
|
|
the source code, or small wibbles in earlier optimisations, could mean
|
... | @@ -83,7 +80,7 @@ handled: |
... | @@ -83,7 +80,7 @@ handled: |
|
f2 x y = <blah>
|
|
f2 x y = <blah>
|
|
```
|
|
```
|
|
|
|
|
|
Here `f1` will be inlined when it is applied to one arugment, but `f2` will only be inlined if it appears applied to two arguments. This turns out to be helpful in reducing gratuitous code bloat.
|
|
Here `f1` will be inlined when it is applied to one argument, but `f2` will only be inlined if it appears applied to two arguments. This turns out to be helpful in reducing gratuitous code bloat.
|
|
|
|
|
|
|
|
|
|
Another important related change is this. Consider
|
|
Another important related change is this. Consider
|
... | @@ -96,7 +93,7 @@ test x = flip y ++ flip y |
... | @@ -96,7 +93,7 @@ test x = flip y ++ flip y |
|
```
|
|
```
|
|
|
|
|
|
|
|
|
|
GHC will not fire rule "foo" because it is scared about duplicating the redec
|
|
GHC will not fire rule "foo" because it is scared about duplicating the redex
|
|
`(flop x)`. However, if you declare that `flop` is CONLIKE, thus
|
|
`(flop x)`. However, if you declare that `flop` is CONLIKE, thus
|
|
|
|
|
|
```wiki
|
|
```wiki
|
... | @@ -115,7 +112,7 @@ before the rule has a chance to fire. |
... | @@ -115,7 +112,7 @@ before the rule has a chance to fire. |
|
|
|
|
|
GHC's back end has been a ferment of activity. In particular,
|
|
GHC's back end has been a ferment of activity. In particular,
|
|
|
|
|
|
- David Terei made a LLVM back end for GHC \[Terei\]. It's not part of the HEAD, but we earnestly hope that it will become so.
|
|
- David Terei made a LLVM back end for GHC [ http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM Terei](http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM Terei). It's not part of the HEAD, but we earnestly hope that it will become so.
|
|
|
|
|
|
- John Dias, Norman Ramsey, and Simon PJ made a lot of progress on Hoopl, our new representaion for control flow graphs, and accompanying functions for dataflow analysis and transformation. There is a paper [ http://research.microsoft.com/en-us/um/people/simonpj/papers/c--/ Hoopl](http://research.microsoft.com/en-us/um/people/simonpj/papers/c--/ Hoopl), and Hoopl itself is now a standalone, re-usable Cabal package, which makes it much easier for others to use.
|
|
- John Dias, Norman Ramsey, and Simon PJ made a lot of progress on Hoopl, our new representaion for control flow graphs, and accompanying functions for dataflow analysis and transformation. There is a paper [ http://research.microsoft.com/en-us/um/people/simonpj/papers/c--/ Hoopl](http://research.microsoft.com/en-us/um/people/simonpj/papers/c--/ Hoopl), and Hoopl itself is now a standalone, re-usable Cabal package, which makes it much easier for others to use.
|
|
|
|
|
... | @@ -131,7 +128,7 @@ The downside is that the code base is in a state of serious flux: |
... | @@ -131,7 +128,7 @@ The downside is that the code base is in a state of serious flux: |
|
There has been a lot of restructuring in the RTS over the past few months, particularly in the area of parallel execution. The biggest change is to the way "blackholes" work: these arise when one thread is evaluating a lazy computation (a "thunk"), and another thread or threads demands the value of the same thunk. Previously, all threads waiting for the result of a thunk were kept in a single global queue, which was traversed regularly. This lead to two performance problems. Firstly, traversing the queue is O(n) in the number of blocked threads, and we recently encountered some benchmarks in which this was the bottleneck. Secondly, there could be a delay between completing a computation and waking up the threads that were blocked waiting for it. Fortunately, we found a design that solves both of these problems, while adding very little overhead.
|
|
There has been a lot of restructuring in the RTS over the past few months, particularly in the area of parallel execution. The biggest change is to the way "blackholes" work: these arise when one thread is evaluating a lazy computation (a "thunk"), and another thread or threads demands the value of the same thunk. Previously, all threads waiting for the result of a thunk were kept in a single global queue, which was traversed regularly. This lead to two performance problems. Firstly, traversing the queue is O(n) in the number of blocked threads, and we recently encountered some benchmarks in which this was the bottleneck. Secondly, there could be a delay between completing a computation and waking up the threads that were blocked waiting for it. Fortunately, we found a design that solves both of these problems, while adding very little overhead.
|
|
|
|
|
|
|
|
|
|
We also fixed another pathalogical performance case: when a large numbers of threads are blocked on an MVar and become unreachable at the same time, reaping all these threads was an O(n<sup>2</sup>) operation. A new representation for the queue of threads blocked on an MVar solved this problem.
|
|
We also fixed another pathological performance case: when a large numbers of threads are blocked on an MVar and become unreachable at the same time, reaping all these threads was an O(n<sup>2</sup>) operation. A new representation for the queue of threads blocked on an MVar solved this problem.
|
|
|
|
|
|
|
|
|
|
At the same time, we rearchitected large parts of the RTS to move from algorithms involving shared data structures and locking to a message-passing style. As things get more complex in the parallel RTS, using message-passing let us simplify some of the invariants and move towards having less shared state between the CPUs, which will improve scaling in the long run.
|
|
At the same time, we rearchitected large parts of the RTS to move from algorithms involving shared data structures and locking to a message-passing style. As things get more complex in the parallel RTS, using message-passing let us simplify some of the invariants and move towards having less shared state between the CPUs, which will improve scaling in the long run.
|
... | @@ -142,10 +139,10 @@ The GC has seen some work too: the goal here is to enable each processor ("capab |
... | @@ -142,10 +139,10 @@ The GC has seen some work too: the goal here is to enable each processor ("capab |
|
### Data Parallel Haskell
|
|
### Data Parallel Haskell
|
|
|
|
|
|
|
|
|
|
In the last months, our focus has been on improving the scalability of the [ Quickhull](http://darcs.haskell.org/packages/dph/examples/quickhull/QuickHullVect.hs) benchmark, and this work is still ongoing. In addition, Roman has invested significant energy into the increasingly popular package [ vector](http://hackage.haskell.org/package/vector-0.6.0.1) and the [ NoSlow](http://hackage.haskell.org/package/NoSlow) array benchmark framework. Package vector is our next-gen sequential array library, and we will replace the current sequential array component (dph-prim-seq) with package vector sometime in the next few months.
|
|
In the last months, our focus has been on improving the scalability of the [ http://darcs.haskell.org/packages/dph/examples/quickhull/QuickHullVect.hs Quickhull](http://darcs.haskell.org/packages/dph/examples/quickhull/QuickHullVect.hs Quickhull) benchmark, and this work is still ongoing. In addition, Roman has invested significant energy into the increasingly popular [ http://hackage.haskell.org/package/vector-0.6.0.1 vector package](http://hackage.haskell.org/package/vector-0.6.0.1 vector package) and the [ http://hackage.haskell.org/package/NoSlow NoSlow](http://hackage.haskell.org/package/NoSlow NoSlow) array benchmark framework. Package vector is our next-gen sequential array library, and we will replace the current sequential array component (dph-prim-seq) with package vector sometime in the next few months.
|
|
|
|
|
|
|
|
|
|
We completed a first release of the regular, multi-dimensional array library introduced in the previous status report. The library is called Repa and is available from Hackage [ Repa package](http://hackage.haskell.org/package/repa). The library supports shape-polymorphism and works with both the sequential and parallel DPH base library. We discuss the use and implementation of Repa in a draft paper [ Repa](http://www.cse.unsw.edu.au/~chak/papers/KCLPL10.html). We have shown that Repa can produce efficient and scalable code for FFT and relaxation algorithms and would be very interested to hear from early adopters who are willing to try Repa out in an application they care about.
|
|
We completed a first release of the regular, multi-dimensional array library introduced in the previous status report. The library is called Repa and is available from Hackage [ http://hackage.haskell.org/package/repa Repa package](http://hackage.haskell.org/package/repa Repa package). The library supports shape-polymorphism and works with both the sequential and parallel DPH base library. We discuss the use and implementation of Repa in a draft paper [ http://www.cse.unsw.edu.au/\~chak/papers/KCLPL10.html Repa](http://www.cse.unsw.edu.au/~chak/papers/KCLPL10.html Repa). We have shown that Repa can produce efficient and scalable code for FFT and relaxation algorithms and would be very interested to hear from early adopters who are willing to try Repa out in an application they care about.
|
|
|
|
|
|
|
|
|
|
At the start of the year, Ben Lippmeier has joined the project. He has started to improve our benchmarks infrastructure and worked on Repa.
|
|
At the start of the year, Ben Lippmeier has joined the project. He has started to improve our benchmarks infrastructure and worked on Repa.
|
... | @@ -161,7 +158,7 @@ At the start of the year, Ben Lippmeier has joined the project. He has started |
... | @@ -161,7 +158,7 @@ At the start of the year, Ben Lippmeier has joined the project. He has started |
|
- Developed some improvments to `containers` that makes it go faster still.
|
|
- Developed some improvments to `containers` that makes it go faster still.
|
|
So `UniqFM` and `FiniteMap` are finally dead. Hurrah for Hackage!
|
|
So `UniqFM` and `FiniteMap` are finally dead. Hurrah for Hackage!
|
|
|
|
|
|
- The [ Threadscope](http://research.microsoft.com/threadscope) tool for visualising parallel execution was released. The tool is ripe for improvement in many ways, if you're interested in helping let us know
|
|
- The [ http://research.microsoft.com/threadscope Threadscope](http://research.microsoft.com/threadscope Threadscope) tool for visualising parallel execution was released. The tool is ripe for improvement in many ways, if you're interested in helping let us know
|
|
|
|
|
|
### Nightly builds
|
|
### Nightly builds
|
|
|
|
|
... | @@ -172,14 +169,26 @@ For some time, it's been clear to us that Buildbot is not the perfect tool for o |
... | @@ -172,14 +169,26 @@ For some time, it's been clear to us that Buildbot is not the perfect tool for o |
|
When the darcs.haskell.org hardware was upgraded, rather than installing buildbot on the new machine, we made the decision to implement a system that better matched our needs instead. The core implementation is now complete, and we have several machines using it for nightly builds.
|
|
When the darcs.haskell.org hardware was upgraded, rather than installing buildbot on the new machine, we made the decision to implement a system that better matched our needs instead. The core implementation is now complete, and we have several machines using it for nightly builds.
|
|
|
|
|
|
|
|
|
|
We're always keen to add more build slaves; please see [ http://hackage.haskell.org/trac/ghc/wiki/Builder](http://hackage.haskell.org/trac/ghc/wiki/Builder) if you're interested. Likewise, patches for missing features are welcome! The (Haskell) code is available at [ http://darcs.haskell.org/builder/](http://darcs.haskell.org/builder/)
|
|
We're always keen to add more build slaves; please see [ http://hackage.haskell.org/trac/ghc/wiki/Builder Builder](http://hackage.haskell.org/trac/ghc/wiki/Builder Builder) if you're interested. Likewise, patches for missing features are welcome! The (Haskell) code is available at [ http://darcs.haskell.org/builder/](http://darcs.haskell.org/builder/)
|
|
|
|
|
|
# Bibliography
|
|
# Bibliography
|
|
|
|
|
|
|
|
- \[Builder\] The GHC builder package [ http://hackage.haskell.org/trac/ghc/wiki/Builder](http://hackage.haskell.org/trac/ghc/wiki/Builder)
|
|
|
|
|
|
- \[Hoopl\] "Hoopl: A Modular, Reusable Library for Dataflow Analysis and Transformation", Norman Ramsey, John Dias, and Simon Peyton Jones, submitted to ICFP'10. [ http://research.microsoft.com/en-us/um/people/simonpj/papers/c--/](http://research.microsoft.com/en-us/um/people/simonpj/papers/c--/)
|
|
- \[Hoopl\] "Hoopl: A Modular, Reusable Library for Dataflow Analysis and Transformation", Norman Ramsey, John Dias, and Simon Peyton Jones, submitted to ICFP'10. [ http://research.microsoft.com/en-us/um/people/simonpj/papers/c--/](http://research.microsoft.com/en-us/um/people/simonpj/papers/c--/)
|
|
|
|
|
|
|
|
- \[NewCodeGen\] The glorious new code generator [ http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen](http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen)
|
|
|
|
|
|
|
|
- \[NoSlow\] The NoSlow array benchmark framework [ http://hackage.haskell.org/package/NoSlow](http://hackage.haskell.org/package/NoSlow)
|
|
|
|
|
|
|
|
- \[Quickhull\] The Quickhull DPH benchmark [ http://darcs.haskell.org/packages/dph/examples/quickhull/QuickHullVect.hs](http://darcs.haskell.org/packages/dph/examples/quickhull/QuickHullVect.hs)
|
|
|
|
|
|
|
|
- \[Repa\] "Regular, shape-polymorphic, parallel arrays in Haskell", Gabriele Keller, Manuel M. T. Chakravarty, Roman Leshchinskiy, Simon Peyton Jones, and Ben Lippmeier, submitted to ICFP'10. [ http://www.cse.unsw.edu.au/\~chak/papers/KCLPL10.html](http://www.cse.unsw.edu.au/~chak/papers/KCLPL10.html)
|
|
|
|
|
|
|
|
- \[Repa package\] The Repa Cabal package [ http://hackage.haskell.org/package/repa](http://hackage.haskell.org/package/repa)
|
|
|
|
|
|
- \[Terei\] The LLVM back end for GHC [ http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM](http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM)
|
|
- \[Terei\] The LLVM back end for GHC [ http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM](http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM)
|
|
|
|
|
|
- \[NewCodeGen\] The glorious new code generator [ http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen](http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen)
|
|
- \[Threadscope\] The Threadscope tool [ http://research.microsoft.com/threadscope](http://research.microsoft.com/threadscope)
|
|
|
|
|
|
- \[Repa\] "Regular, shape-polymorphic, parallel arrays in Haskell", Gabriele Keller, Manuel M. T. Chakravarty, Roman Leshchinskiy, Simon Peyton Jones, and Ben Lippmeier, submitted to ICFP'10. [ http://www.cse.unsw.edu.au/\~chak/papers/KCLPL10.html](http://www.cse.unsw.edu.au/~chak/papers/KCLPL10.html) |
|
- \[vector package\] The vector Cabal package [ http://hackage.haskell.org/package/vector-0.6.0.1](http://hackage.haskell.org/package/vector-0.6.0.1) |
|
\ No newline at end of file |
|
\ No newline at end of file |