Sorry, I am not communicating this well tonight... distracted with other things.<div><br></div><div>Please ignore the obviously confusing and incorrect statements earlier, I'll try to explain from scratch.</div><div><br>
</div><div>What I originally observed, very roughly:</div><div><br></div><div>compile_time(N*size) < 2 * N * compile_time(size)</div><div><br></div><div>I started with 4 test cases: 0.5k, 1k, 2k, 4k in "size"</div>
<div><br></div><div>0.5k compiled in under 1 second</div><div>1k compiled in under 2 seconds</div><div>2k compiled in under 4 seconds</div><div>4k compiled in under 8 seconds</div><div><br></div><div>This did not look quadratic to me at first -- the time is a linear product of the size. And no, this is not at all what my original email stated, my english skills failed me there.</div>
<div><br></div><div>Alas, in the way of things, these are not very precise measurements, and there are very many other factors at play. I gathered repeated measurements, but they're still very noisy.</div><div><br></div>
<div>When I continued to collect more data points further out to better establish any remaining problems or curves, a new super-linear growth curve emerged:</div><div><br></div><div>8k compiled in around 32 seconds</div><div>
16k compiled in around 180 seconds</div><div>32k compiled in around 1200 seconds (but at this point, my machine started swapping, so all bets off).</div><div><br></div><div>This is what I hinted at in my last mail... The profiles of these much larger compilations point to very different parts of the code generator, so they don't likely have anything to do with this patch other than this patch allowing us to see them. Previously, they didn't dominate the performance.</div>
<div><br></div><div>Hope this reduces confusion some, sorry about all that.</div><div>-Chandler</div><div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 6, 2012 at 3:20 AM, Jay Foad <span dir="ltr"><<a href="mailto:jay.foad@gmail.com" target="_blank">jay.foad@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 class="im">On 6 July 2012 09:42, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br>

> It doesn't grow by the size of the input squared, it grows by a constant<br>
> factor of the size of the input, the constant happens to be "2" instead of<br>
> "1".<br>
<br>
</div>So on input size n, the runtime is 2n. (*)<br>
<div class="im"><br>
> Thus if I double the size of the input, I quadruple the runtime.<br>
<br>
</div>No. Input size 2n ==> runtime 4n. Both have doubled.<br>
<div class="im"><br>
> It<br>
> isn't quadratic unless when I quadruple the size of the input, it multiplies<br>
> the time by 16 (4*4) -- currently it just multiplies it by 8 (2 * 4).<br>
<br>
</div>You're telling me that doubling input size quadruples runtime, but two<br>
successive doublings don't give two successive quadruplings.<br>
Seriously?<br>
<br>
(*) Obviously the units are arbitrary here, which makes the constant<br>
factor arbitrary too. This is very basic big-O notation stuff.<br>
<div class="HOEnZb"><div class="h5"><br>
Jay.<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>