[Haskell-cafe] Two GHC-related GSoC Proposals

[Patrick Palka]

GHC for the most part is already thread-safe. There are a few data
structures that persist between module compilations, but they're mostly
just caches that're already modified in an atomic fashion. Interleaving
updates to these caches shouldn't cause any problems as long as the updates
are done atomically. There is also a bit of top-level global state that
needs attention, like the FastString table, the PersistentLinkerState and
the unique-supply counter. The GHCi linker may need to be made thread-safe,
and so will the interface loader. Deletion of temporary files will need to
be handled more carefully. And.. that's about it as far as making the
compiler thread safe goes, I think. The rest of the compilation pipeline
just performs benign side effects, if any at all. Of course, unforeseen
issues will pop up but I think I have enough baseline experience and
familiarity with the GHC codebase to be able to complete the project within
the given time frame. (Or maybe I'm just being naive -- there must be a
good reason why it hasn't yet been done!)

Thanks for your feedback.



On Sun, Apr 21, 2013 at 4:35 PM, Alp Mestanogullari <alpmestan at gmail.com>wrote:

> 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/11114780/attachment.htm>