<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 8:01 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</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"><div class="im">On Thu, Oct 24, 2013 at 4:50 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Oct 23, 2013 at 3:44 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@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>On 23 October 2013 00:26, Daniel Dunbar <<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>> wrote:<br>
> I wanted to have a little bit of time to check out how things were on<br>
> Windows, but I haven't found it.<br>
><br>
> Off the top of my head, I think that was the main thing, other than also<br>
> just giving it a little bake time.<br>
><br>
> We could go ahead and switch the default for non-Windows and see what<br>
> happens if you are interested...<br>
<br>
</div>Probably a good idea. With check-all the time goes from 1m10.644s to<br>
0m50.506s in my machine :-)<br></blockquote><div><br></div></div></div><div>Wow, that means that 20s of the check-all time were just lit overhead, which is insane.</div></div></div></div></blockquote><div><br></div></div>
<div>
No, it doesn't, it means that 20s of check-all time could be saved by increased parallelism.</div></div></div></div></blockquote><div><br></div><div>Oh, I thought that the change to multiprocessing didn't affect the number of jobs spawned? Is multiprocessing automatically selecting a better job count, or what is the source of this huge performance discrepancy?</div>
<div><br></div><div>-- Sean Silva</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"><div class="gmail_quote"><div>
<br></div><div>The lit overhead is fairly small, you can check it by running with --no-execute. On my machine for just LLVM, lit can "run" all the tests in <3s if it doesn't actually execute them -- this includes the time for discovery, and reading and parsing every single test script. It takes < .5s to handle just discovery and processing of all the tests without reading and parsing the test scripts, so you can see that most of the time is in parsing the "ShTest" format, but even that is a small percentage of the overall testing time.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div> - Daniel</div></font></span><div class="im"><div><br></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">
<div class="gmail_quote"><div>
Can you estimate the total lit overhead after switching to multiprocessing? E.g., can we gain another 20s of check-all speed by reducing lit overhead?</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
Cheers,<br>
Rafael<div><br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">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></div></blockquote></div><br></div></div>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>