Hi,
I think the first proposal may be a bit too much for a GSoC, depending on
how much you actually are familiar with the code base. If you can write
down everything that needs to be done, in a detailed way (I mean a *lot* of
details), for each of these steps, and if you sincerely consider all of
these stuffs can be done in 3 months, yeah, that would be great! For
example, making the compilation pipeline thread safe may end up being
trickier than expected if it's not studied properly before making a
proposal.
The latter is a good idea, and a good proposal would ideally include some
estimation on how it can impact some benchmarks/projects. It looks much
less like a "trap" and if you propose enough improvements that it can fill
a whole GSoC, considering how big the impact can be, yes, this would of
course be a good idea.
On Sun, Apr 21, 2013 at 6:20 PM, Patrick Palka
Hi,
I'm interested in participating in the GSoC by improving GHC with one of these two features:
1) Implement native support for compiling modules in parallel (see #910http://hackage.haskell.org/trac/ghc/ticket/910). This will involve making the compilation pipeline thread-safe, implementing the logic for building modules in parallel (with an emphasis on keeping compiler output deterministic), and lots of testing and benchmarking. Being able to seamlessly build modules in parallel will shorten the time it takes to recompile a project and will therefore improve the life of every GHC user.
2) Improve existing constant folding, strength reduction and peephole optimizations on arithmetic and logical expressions, and optionally implement a core-to-core pass for optimizing nested comparisons (relevant tickets include #2132 http://hackage.haskell.org/trac/ghc/ticket/2132, #5615 http://hackage.haskell.org/trac/ghc/ticket/5615,#4101http://hackage.haskell.org/trac/ghc/ticket/4101). GHC currently performs some of these simplifications (via its BuiltinRule framework), but there is a lot of room for improvement. For instance, the core for this snippet is essentially identical to the Haskell source:
foo :: Int -> Int -> Int -> Int foo a b c = 10*((b+7+a+12+b+9)+4) + 5*(a+7+b+12+a+9) + 7 + b + c
Yet the RHS is actually equivalent to
20*a + 26*b + c + 467
And:
bar :: Int -> Int -> Int bar a b = a + b - a - b -- the RHS is should be optimized away to 0
Other optimizations include: multiplication and division by powers of two should be converted to shifts; multiple plusAddr calls with constant operands should be coalesced into a single plusAddr call; floating point functions should be constant folded, etc..
GHC should be able to perform all these algebraic simplifications. Of course, emphasis should be placed on the correctness of such transformations. A flag for performing unsafe optimizations like assuming floating point arithmetic is associative and distributive should be added. This proposal will benefit anybody writing or using numerically intensive code.
I'm wondering what the community thinks of these projects. Which project is a better fit for GSoC, or are both a good fit? Is a mentor willing to supervise one of these projects?
Thanks for your time. Patrick
(A little about myself: I'm a Mathematics student in the US, and I've been programming in Haskell for about 3.5 years. Having a keen interest in Haskell and compilers, I began studying the GHC source about 1 year ago and I've since gotten a good understanding of its internals, contributing a few patches along the way.)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Alp Mestanogullari