[LLVMdev] Experimental Evaluation of the Schedulers in LLVM 3.3
atrick at apple.com
Mon Sep 23 23:22:00 PDT 2013
On Sep 17, 2013, at 11:04 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com> wrote:
> 1. The SD schedulers significantly impact the spill counts and the execution times for many benchmarks, but the machine instruction (MI) scheduler in 3.3 has very limited impact on both spill counts and execution times. Is this because most of you work on MI did not make it into the 3.3 release? We don't have a strong motivation to test the trunk at this point (we'll wait for 3.4), because we are working on a publication and prefer to base that on an official release. However, if you tell me that you expect things to be significantly different in the trunk, we'll try to find the time to give that a shot (unfortunately, we only have one test machine, and SPEC tests take a lot of time as detailed below).
> Most of the above performance differences have been correlated with significant changes in spill counts in hot functions. Note that the ILP scheduler causes a degradation of 22% on one benchmark (lbm) relative to the source scheduler. We have verified that this happens because of poor scheduling that increases the register pressure and thus leads to generating excessive spills in this benchmark’s hottest loop. We should probably report this as a performance bug if ILP stays the default scheduler on x86-64.
The life of ILP as default scheduler is numbered in days.
Regarding your publication. It's fine to use BURR with 3.3 and call it the best LLVM scheduler for your set of benchmarks. Even though the default MI scheduler on trunk has improved, I doubt it will beat BURR at average register pressure reduction (as I mentioned in a previous email, we decided not to enable global register pressure heuristics). I did notice a 10% improvement on 470.lbm at some point after 3.3, but you would need to verify.
In 3.4, the SD scheduler may still be available, but won't be maintained. So I recommend using MI scheduler for baselines.
Note that you can easily plug in alternate scheduling heuristics using the MI scheduler. It wouldn't be hard to implement a BURR strategy for the new scheduler.
For the purpose of evaluating register reduction, I agree that your spill metric is a reasonable indicator. It is true that we will readily trade a single spill inside a loop for multiple spills outside. But it seems good enough for evaluating different versions of the scheduler before gathering your final numbers for publication. That gets you results in minutes instead of days.
I’m not really sure why spills have such an impact on your SPEC2006 performance, whether it’s critical path load latency, load bandwidth (SandyBridge has doubled this), decode bandwidth, or even loop stream detector capacity.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev