... | @@ -8,20 +8,126 @@ In the past 6 months we have made the first 2 releases from the 6.12 branch. 6.1 |
... | @@ -8,20 +8,126 @@ In the past 6 months we have made the first 2 releases from the 6.12 branch. 6.1 |
|
|
|
|
|
GHC 6.12.2 will also be included in the upcoming Haskell Platform release ([ http://hackage.haskell.org/platform/](http://hackage.haskell.org/platform/)). The Haskell platform is the recommended way for end users to get a Haskell development environment.
|
|
GHC 6.12.2 will also be included in the upcoming Haskell Platform release ([ http://hackage.haskell.org/platform/](http://hackage.haskell.org/platform/)). The Haskell platform is the recommended way for end users to get a Haskell development environment.
|
|
|
|
|
|
## Ongoing work
|
|
### Ongoing work
|
|
|
|
|
|
|
|
|
|
Meanwhile, in the HEAD, the last 6 months have seen more than 1000 patches pushed from more than a dozen contributors. As the following graph shows, tickets are still being opened faster than we can close them, with the total open tickets growing from around 700 to almost 800. We will be looking in the near future at improving the effectiveness of the way we use the bug tracker.
|
|
Meanwhile, in the HEAD, the last 6 months have seen more than 1000 patches pushed from more than a dozen contributors. As the following graph shows, tickets are still being opened faster than we can close them, with the total open tickets growing from around 700 to almost 800. We will be looking in the near future at improving the effectiveness of the way we use the bug tracker.
|
|
|
|
|
|
[](/trac/ghc/attachment/wiki/Status/Apr10/GHC_trac_tickets.png)
|
|
[](/trac/ghc/attachment/wiki/Status/Apr10/GHC_trac_tickets.png)
|
|
|
|
|
|
- Hoopl and the back end (incl LLVM). **Simon PJ**.
|
|
### Language changes
|
|
- Containers: **Simon PJ and Milan**.
|
|
|
|
- TH quasi-quoting improvements (simpler syntax, types and decls): **Simon PJ**
|
|
|
|
- Type system generally **Simon PJ**
|
|
We have made a few small language improvements.
|
|
- Inliner changes (incl CONLIKE) **Simon PJ**
|
|
|
|
- Data parallel Haskell: **Manuel**
|
|
|
|
- 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!
|
|
Kathleen Fisher suggested two improvements to quasi-quotation:
|
|
|
|
|
|
|
|
- Quasi-quotes can now appear as a top-level declaration, or in a type, as well
|
|
|
|
as in a pattern or expression.
|
|
|
|
- Quasi-quotes have a less noisy syntax.
|
|
|
|
|
|
|
|
|
|
|
|
Here's an example that illustrates both:
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
f x = x+1
|
|
|
|
[pads| ...blah..blah... |]
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
The second delaration uses the quasi-quoter called `pads` (which must
|
|
|
|
be in scope) to parse the "...blah..blah..", and return a list of
|
|
|
|
Template Haskell declarations, which are then spliced into the program
|
|
|
|
in place of the quote.
|
|
|
|
|
|
|
|
## Type system
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
rewrite the constraint solver, which forms the heart of the type
|
|
|
|
inference engine, and that remains the plan although he is being slow
|
|
|
|
about it. (The existing constraint solver works surprisingly
|
|
|
|
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;
|
|
|
|
watch Simon's home page.
|
|
|
|
|
|
|
|
### The mighty simplifier
|
|
|
|
|
|
|
|
|
|
|
|
One of GHC's most crucial optimisers is the Simplifier, which is
|
|
|
|
reponsible for many local transformations, plus applying inlining and
|
|
|
|
rewrite-rules. Over time it had become apparent that the
|
|
|
|
implementation of INLINE pragmas wasn't very robust: small changes in
|
|
|
|
the source code, or small wibbles in earlier optimisations, could mean
|
|
|
|
that something with an INLINE pragma wasn't inlined when it should be,
|
|
|
|
or vice versa.
|
|
|
|
|
|
|
|
|
|
|
|
Simon PJ therefore completely re-engineered the way INLINE pragmas are
|
|
|
|
handled:
|
|
|
|
|
|
|
|
- GHC now takes a "snapshot" of the original RHS of a function with an INLINE pragma.
|
|
|
|
|
|
|
|
- The function is now optimised as normal, but when the function is
|
|
|
|
inlined it is the snapshot, not the current RHS, that is inlined.
|
|
|
|
|
|
|
|
- The function is inlined only when it is applied to as many arguments as the LHS of its original definition. Consider;
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
f1, f2 :: Int -> Int -> Int
|
|
|
|
{-# INLINE f1 #-}
|
|
|
|
f1 x = \y -> <blah>
|
|
|
|
{-# INLINE f2 #-}
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Another important related change is this. Consider
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
{-# RULE "foo" flip (flop x) = <blah> #-}
|
|
|
|
test x = flip y ++ flip y
|
|
|
|
where
|
|
|
|
y = flop x
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
GHC will not fire rule "foo" because it is scared about duplicating the redec
|
|
|
|
`(flop x)`. However, if you declare that `flop` is CONLIKE, thus
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
{-# NOINLINE [1] CONLIKE flop #-}
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
This declares that an application of `flop` is cheap enough that even a shared
|
|
|
|
application can participate in a rule application. The CONLIKE pragma is a modifier
|
|
|
|
on a NOINLINE (or INLINE) pragma, becuase it really only makes sense to match
|
|
|
|
`flop` on the LHS of a rule if you know that `flop` is not going to be inlined
|
|
|
|
before the rule has a chance to fire.
|
|
|
|
|
|
|
|
### The back end
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
The downside is that the code base is in a state of serious flux:
|
|
|
|
|
|
|
|
- We still have two back-end pipelines, because we don't trust the new one to drop the old one. See Commentary/Compiler/NewCodeGen NewCodeGen?.
|
|
|
|
- We are in the midst of pushing the new Hoopl into GHC.
|
|
|
|
|
|
|
|
# Stuff waiting for other people to fill in
|
|
|
|
|
|
|
|
- Data parallel Haskell: Manuel
|
|
|
|
|
|
### Runtime system work (SimonM)
|
|
### Runtime system work (SimonM)
|
|
|
|
|
... | @@ -37,6 +143,19 @@ At the same time, we rearchitected large parts of the RTS to move from algorithm |
... | @@ -37,6 +143,19 @@ At the same time, we rearchitected large parts of the RTS to move from algorithm |
|
|
|
|
|
The GC has seen some work too: the goal here is to enable each processor ("capability" in the internal terminology) to collect its private heap independently of the other processors. It turns out that this is quite tricky to achieve in the context of the current architecture, but we have made some progress in this direction by privatising more of the global state and simplifying the GC data structures by removing the concept of "steps", while keeping a simple aging policy which is what steps gave us previously.
|
|
The GC has seen some work too: the goal here is to enable each processor ("capability" in the internal terminology) to collect its private heap independently of the other processors. It turns out that this is quite tricky to achieve in the context of the current architecture, but we have made some progress in this direction by privatising more of the global state and simplifying the GC data structures by removing the concept of "steps", while keeping a simple aging policy which is what steps gave us previously.
|
|
|
|
|
|
|
|
## Other miscellaneous stuff
|
|
|
|
|
|
|
|
- GHC makes heavy use of sets and finite maps. Up till now it has used
|
|
|
|
its own home-grown `UniqFM` and `FiniteMap` modules. Milan Straka (visiting as
|
|
|
|
an intern from the Czech Republic) has
|
|
|
|
|
|
|
|
- Made GHC use the `containers` package instead, which happily makes
|
|
|
|
compilation go a few percent faster.
|
|
|
|
- Developed some improvments to `containers` that makes it go faster still.
|
|
|
|
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
|
|
|
|
|
|
### Nightly builds
|
|
### Nightly builds
|
|
|
|
|
|
|
|
|
... | @@ -46,4 +165,12 @@ For some time, it's been clear to us that Buildbot is not the perfect tool for o |
... | @@ -46,4 +165,12 @@ 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](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/)
|
|
\ No newline at end of file |
|
|
|
|
|
# Bibliography
|
|
|
|
|
|
|
|
- \[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--/)
|
|
|
|
|
|
|
|
- \[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) |
|
|
|
\ No newline at end of file |