Re: [Haskell-cafe] Two GHC-related GSoC Proposals

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 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 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 #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