[Haskell-cafe] Two GHC-related GSoC Proposals

[Alp Mestanogullari]

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 <patrick at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Alp Mestanogullari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130421/c744f284/attachment.htm>