<div dir="ltr">On Wed, Jul 31, 2013 at 10:42 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 1:35 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the sequential part of that step should be in the core code, but the parallelization will be in a (small) tool. This is also where special-case logic for custom networked file systems or strange version control systems would fall in.</blockquote>

</div><br></div>I really disagree. I don't know why we wouldn't aim to eventually have the core clang logic know all the necessary tricks to scalaing all aspects of this up. It shouldn't be sequestered like this.</div>
</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><br></div><div class="gmail_extra">Consider, if you have the ability to do any amount of parallelism in the tool, you'd often like to pipeline the analysis and the updating of files, all while maintaining de-dup coherency etc. This would essentially require the same code to be managing both the running of the tool and the writing of the updates. In the case where you *don't* serialize the edits through some other layer, I think you still will want this, and thus it belongs in common shared library code.</div>
</div></blockquote><div><br></div><div>While in an ideal world I would agree, I think the possible parallelization frameworks we'll want to support are different enough that we always want the parallelization framework to drive the analysis, and provide atoms that can be put together effectively to achieve that.</div>
<div><br></div><div>I'm not saying that we shouldn't provide some common mechanism for parallelizing in the core, I just think we need to architect it in a way that the parallelization can be driven from outside, at which point the parallelization in the core becomes less central to the whole design, and thus I think less important to argue about.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Naturally parallelism within a process of this kind (or any kind) of this kind is a long way off. I just don't want to not be thinking about it in terms of what the end goal looks like.</div>

</div>
</blockquote></div><br></div></div>