It&#39;s also useful to note that the disk cache might do a surprisingly good job at caching those .hi files for you. That, and a lot of people (like me!) use SSDs, where the parallel compilation takes the vast majority of time.<div>
<br></div><div>I&#39;d be really excited to see parallel ghc --make.</div><div><br></div><div>By the way, totally unrelated, but why does cabal support -j when cabal-dev doesn&#39;t?</div><div><br></div><div>  - Clark<br>
<br>On Wednesday, May 15, 2013, Niklas Hambüchen  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Thomas,<br>
<br>
thanks for your detailed answer.<br>
<br>
&gt; Could be worthwhile re-evaluating the patch.<br>
<br>
Does your patch still apply somewhat cleanly?<br>
And does it address all the caches in your list already or only some<br>
subset of them?<br>
<br>
&gt; To have a multi-process ghc --make you don&#39;t need thread-safety.<br>
&gt; However, without sharing the caches -- in particular the interface<br>
&gt; file caches -- the time to read data from the disk may outweigh any<br>
&gt; advantages from parallel execution.<br>
<br>
That might be a big step already - I&#39;ve never seen a project where I&#39;d<br>
care about parallel compilation that is not totally CPU-bound.<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Haskell-Cafe@haskell.org&#39;)">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>
</blockquote></div>