<div dir="ltr"><div style>What's the plan for what control / synchronization structures you'll use in part 2 of the plan to implement a parallel driver?</div><div style><br></div><div style>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, and only add modules to the work queue when all their dependencies are met (limits memory use)... many options for executing a task DAG. Fortunately the granularity is coarse.</div>
<div style><br></div><div style> -Ryan</div><div style><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 21, 2013 at 10:34 PM, Patrick Palka <span dir="ltr"><<a href="mailto:patrick@parcs.ath.cx" target="_blank">patrick@parcs.ath.cx</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 would expose new information to subsequent core-to-core passes. Also, Haskell has different overflow rules than C does (whose rules I assume LLVM's optimizations are modeled from): In Haskell, integer overflow is undefined for all integral types, whereas in C it's only undefined for signed integral types. This limits the number of optimizations a C-based optimizer can perform on unsigned arithmetic.<div>
<br></div><div>I'm not sure how I would break up the parallel compilation proposal into multiple self-contained units of work. I can only think of two units: making GHC thread safe, and writing the new parallel compilation driver. Other incidental units may come up during development (e.g. parallel compilation might exacerbate <a href="http://hackage.haskell.org/trac/ghc/ticket/4012" target="_blank">#4012</a>), but I still feel that three months of full time work is ample time to complete the project, especially with existing familiarity with the code base.</div>
<div><br></div><div>Thanks for the feedback.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 21, 2013 at 5:55 PM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Patrick,<div>both are excellent ideas for work that would be really valuable for the community! </div>
<div>(independent of whether or not they can be made into GSOC sided chunks )</div><div>
<br></div><div>-------</div><div>I'm actually hoping to invest some time this summer investigating improving the numerics optimization story in ghc. This is in large part because I'm writing LOTs of numeric codes in haskell presently (hopefully on track to make some available to the community ). </div>
<div><br></div><div>That said, its not entirely obvious (at least to me) what a tractable focused GSOC sized subset of the numerics optimization improvement would be, and that would have to also be a subset that has real performance impact and doesn't benefit from eg using -fllvm rather than -fasm .</div>
<div>---------</div><div><br></div><div>For helping pave the way to better parallel builds, what are some self contained units of work on ghc (or related work on cabal) that might be tractable over a summer? If you can put together a clear roadmap of "work chunks" that are tractable over the course of the summer, I'd favor choosing that work, especially if you can give a clear outline of the plan per chunk and how to evaluate the success of each unit of work.</div>
<div><br></div><div>basically: while both are high value projects, helping improve the parallel build tooling (whether in performance or correctness or both!) has a more obvious scope of community impact, and if you can layout a clear plan of work that GHC folks agree with and seems doable, i'd favor that project :) </div>
<div><br></div><div>hope this feedback helps you sort out project ideas</div><div><br></div><div>cheers</div><span><font color="#888888"><div>-Carter</div><div><br></div><div><br></div></font></span></div>
<div class="gmail_extra">
<br><br><div class="gmail_quote"><div><div>On Sun, Apr 21, 2013 at 12:20 PM, Patrick Palka <span dir="ltr"><<a href="mailto:patrick@parcs.ath.cx" target="_blank">patrick@parcs.ath.cx</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<div dir="ltr">Hi,<div><br></div><div>I'm interested in participating in the GSoC by improving GHC with one of these two features:</div><div><br></div><div>1) Implement native support for compiling modules in parallel (see <a href="http://hackage.haskell.org/trac/ghc/ticket/910" target="_blank">#910</a>). 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.</div>
<div><br></div><div>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 <a href="http://hackage.haskell.org/trac/ghc/ticket/2132" target="_blank">#2132</a>,<a href="http://hackage.haskell.org/trac/ghc/ticket/5615" target="_blank">#5615</a>,<a href="http://hackage.haskell.org/trac/ghc/ticket/4101" target="_blank">#4101</a>). 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:</div>
<div><br></div><div><div>foo :: Int -> Int -> Int -> Int</div><div>foo a b c = 10*((b+7+a+12+b+9)+4) + 5*(a+7+b+12+a+9) + 7 + b + c</div></div><div><br></div><div>Yet the RHS is actually equivalent to</div>
<div><br></div><div>20*a + 26*b + c + 467</div><div><br></div><div>And:</div><div><br></div><div>bar :: Int -> Int -> Int</div><div>bar a b = a + b - a - b -- the RHS is should be optimized away to 0</div>
<div><br></div><div>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..</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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?</div>
<div><br></div><div><div>Thanks for your time.</div><div>Patrick</div><div><br></div><div><div>(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.)</div>
<div><br></div></div></div></div>
<br></div></div><div>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div></div>