<div dir="ltr">On 17 September 2013 19:04, Ghassan Shobaki <span dir="ltr"><<a href="mailto:ghassan_shobaki@yahoo.com" target="_blank">ghassan_shobaki@yahoo.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:arial,helvetica,sans-serif">


<div class="">We have done some experimental evaluation of the different schedulers in LLVM 3.3 (source, BURR, ILP, fast, MI). The evaluation was done
on x86-64 using SPEC CPU2006. We have measured both the amount of spill code as
well as the execution time as detailed below.<br></div></div></div></blockquote><div><br></div><div>Hi Ghassan,</div><div><br></div><div>This is an amazing piece of work, thanks for doing this. We need more benchmarks like yours, and more often, too.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:arial,helvetica,sans-serif">
<div class=""><span style="font-size:12pt">3. The source scheduler is the second best scheduler in terms of spill code and
execution time, and its performance is very close to that of BURR in both
metrics. This result is surprising for me, because, as far as I understand,
this scheduler is a conservative scheduler that tries to preserve the original
program order, isn't it? Does this result surprise you?</span></div></div></div></blockquote><div><br></div><div>Well, SPEC is an old benchmark, when code was written to accommodate the hardware requirements, so preserving the code order might not be that big of a deal on SPEC, as it is on other types of code. So far, I haven't found SPEC being too good to judge overall compilers' performance, but specific micro-optimized features.</div>
<div><br></div><div>Besides, hardware and software are designed nowadays based on some version of Dhrystone, EEMBC, SPEC or CoreMark, so it's not impossible to see 50% increase in performance with little changes in either.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:arial,helvetica,sans-serif">
<div class=""><span style="font-size:12pt">4. The ILP scheduler has the worst execution times on FP2006 and the second
worst spill counts, although it is the default on x86-64. Is this surprising?
BTW, Dragon Egg sets the scheduler to source. On Line 368 in Backend.cpp, we
find:</span><br></div>

<div class="">if (!flag_schedule_insns)</div>

<div class=""><span>   
</span>Args.push_back("--pre-RA-sched=source");</div></div></div></blockquote><div><br></div><div>This looks like someone ran a similar test and did the sensible thing. How that reflects with Clang, or how important it is to be the default, I don't know. This is the same discussion as the optimization levels, and what passes should be included in what. It also depends on which scheduler will evolve faster or further in time, and what kind of code you're compiling...</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:arial,helvetica,sans-serif">
<div class=""><span style="font-size:12pt">This is not a perfectly accurate
metric, but, given the large sample size (> 10K functions), the total number
of spills across such a statistically significant sample is believed to give a
very strong indication about each scheduler's performance at reducing register
pressure.</span></div></div></div></blockquote><div><br></div><div>I agree this is a good enough metric, but I'd be cautious in stating that there is a "very strong indication about each scheduler's performance". SPEC is, after all, a special case in compiler/hardware world, and anything you see here might not happen anywhere else. </div>
<div><br></div><div>Real world, modern code, (such as LAMP stack, browsers, office suites, etc) are written expecting the compiler to do magic, while old-school benchmarks weren't, and they were optimized for decades by both compiler and hardware engineers.</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:arial,helvetica,sans-serif">
<div class=""><span style="font-size:12pt">The %Diff Max (Min) is the maximum (minimum) percentage difference on a single
benchmark between each scheduler and the source scheduler. </span><span style="font-size:12pt">These numbers show the differences on individual FP benchmarks </span><span style="font-size:12pt">can be quite significant.</span></div>
</div></div></blockquote><div><br></div><div>I'm surprised that you didn't run "source" 5/9 times, too. Did you get the exact performance numbers multiple times? Would be good to have a more realistic geo-mean for source as well, so we could estimate how much the other geo-means vary in comparison to source's.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:arial,helvetica,sans-serif">


<div class="">Most of the above performance differences have been correlated with significant changes in spill counts in hot functions.</div></div></div></blockquote><div><br></div><div>Which is a beautiful correlation between spill-rate and performance, showing that your metrics are at least reasonably accurate, for all purposes.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:arial,helvetica,sans-serif">
<div class="">We should
probably report this as a performance bug if ILP stays the default scheduler on
x86-64.</div></div></div></blockquote><div><br></div><div>You should, regardless of what's the default choice.</div><div><br></div><div>cheers,<br></div><div>--renato</div><div></div></div></div><div class="gmail_extra">
<br></div></div>