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 <patr...@parcs.ath.cx> wrote: > 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 > #910<http://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>,#4101<http://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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe