<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&#39;m actually hoping to invest some time this summer investigating improving the numerics optimization story in ghc. This is in large part because I&#39;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&#39;t benefit from eg using -fllvm rather than -fasm .</div>

<div>---------</div><div style><br></div><div style>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 &quot;work chunks&quot; that are tractable over the course of the summer, I&#39;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 style><br></div><div style>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&#39;d favor that project :) </div>

<div style><br></div><div style>hope this feedback helps you sort out project ideas</div><div style><br></div><div style>cheers</div><div style>-Carter</div><div style><br></div><div style><br></div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Sun, Apr 21, 2013 at 12:20 PM, Patrick Palka <span dir="ltr">&lt;<a href="mailto:patrick@parcs.ath.cx" target="_blank">patrick@parcs.ath.cx</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Hi,<div><br></div><div>I&#39;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 -&gt; Int -&gt; Int -&gt; 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 -&gt; Int -&gt; 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&#39;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&#39;m a Mathematics student in the US, and I&#39;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&#39;ve since gotten a good understanding of its internals, contributing a few patches along the way.)</div>


<div><br></div></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>