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

Right, these optimizations are done on the unboxed level, where bottom is not a concern. GHC would transform bar a b = a + b - a - b to bar (I# a) (I# b) = I# (a +# b -# a -# b) whose RHS could be optimized away to I# 0#. bar is still strict in its two arguments, so calling bar undefined undefi

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

It is not obvious that semantics is preserved for optimisations which remove non-constants like bar a b = a + b - a - b -- the RHS is should be optimized away to 0 Calling bar undefined undefined throws an error, but the optimised bar would return 0. On Sat, Jun 1, 2013 at 8:10 PM, Patrick Palka

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

Yeah, I am going to use the MVar approach. Alternative implementations will be investigated if this approach happens to not scale well. On Fri, May 31, 2013 at 9:10 AM, Thomas Schilling wrote: > [I'll be the mentor for this GSoC project.] > > I used the MVar approach a while ago and so did Simon

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

[I'll be the mentor for this GSoC project.] I used the MVar approach a while ago and so did Simon Marlow's original solution. Using MVars and Threads for this should scale well enough (1000s of modules) and be relatively straightforward. Error/exception handling could be a bit tricky, but you cou

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

What's the plan for what control / synchronization structures you'll use in part 2 of the plan to implement a parallel driver? Is the idea just to use an IO thread for each compile and block them on MVars when they encounter dependencies? Or you can use a pool of worker threads and a work queue,

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

Good points. I did not take into account whether proposal #2 may be worth it in light of -fllvm. I suppose that even if the LLVM codegen is able to perform similar optimizations, it would still be beneficial to implement proposal #2 as a core-to-core pass because the transformations it performs wou

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 ato

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

Hey Patrick, both are excellent ideas for work that would be really valuable for the community! (independent of whether or not they can be made into GSOC sided chunks ) --- I'm actually hoping to invest some time this summer investigating improving the numerics optimization story in ghc. This

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

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

[Haskell-cafe] Two GHC-related GSoC Proposals

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). This will involve making the compilation pipeline thread-safe, implementing th