Iterative optimization for the data center

Abstract

Iterative optimization is a simple but powerful approach that searches for the best possible combination of compiler optimizations for a given workload. However, each program, if not each data set, potentially favors a different combination. As a result, iterative optimization is plagued by several practical issues that prevent it from being widely used in practice: a large number of runs are required for finding the best combination; the process can be data set dependent; and the exploration process incurs significant overhead that needs to be compensated for by performance benefits.Therefore, while iterative optimization has been shown to have significant performance potential, it is seldomly used in production compilers. In this paper, we propose Iterative Optimization for the Data Center (IODC): we show that servers and data centers offer a context in which all of the above hurdles can be overcome. The basic idea is to spawn different combinations across workers and recollect performance statistics at the master, which then evolves to the optimum combination of compiler optimizations. IODC carefully manages costs and benefits, and is transparent to the end user. We evaluate IODC using both MapReduce and throughput compute-intensive server applications. In order to reflect the large number of users interacting with the system, we gather a very large collection of data sets (at least 1000 and up to several million unique data sets per program), for a total storage of 10.7TB, and 568 days of CPU time. We report an average performance improvement of 1.48×, and up to 2.08×, for the MapReduce applications, and 1.14×, and up to 1.39×, for the throughput compute-intensive server applications.

Practical Iterative Optimization for the Data Center

“…(3) How does the strategy perform when datasets are nonuniformly mixed? We briefly answer them here, and more details can be found in the original conference paper [Chen et al 2012]. For the first question, we find that steady-state performance of IODC is within 98% of the best possible performance, in large part because IODC can keep the overhead of recompilations and training runs small.…”

“…The initialization phase does not take that long; after a couple thousand runs (2,670 runs on average), IODC yields a net performance benefit; the reason is that combinations that outperform the default -O3 production combination can usually be found quickly. We show the cumulated speedup profiles for six out of nine benchmarks (including three newly added benchmarks over the conference paper) in Figure 10; the other three benchmarks are shown in the conference paper [Chen et al 2012]. Overall, the proposed strategy achieves a cumulated speedup of 1.39× for bzip2e, 1.12× for blackscholes and freqmine, 1.10× for x264, 1.09× for kmeans and vips, 1.08× for canneal, 1.07× for streamcluster, and 1.06× for ferret, with an average of 1.12×.…”

“…To bring IODC to practice, we evaluate it in the presence of co-runners to better reflect real-life data center operation with multiple applications co-running per server. We enhance IODC Extension of Conference Paper: This article is an extension of a previously published conference paper at ASPLOS 2012 [Chen et al 2012]. The article contains the following contributions over the prior paper:…”

Autotuning algorithmic choice for input sensitivity

“…In the dynamic autotuning space, there have been a number of systems developed [10,12,14,15,24,26,27,31,40] that focus on creating applications that can monitor and automatically tune themselves to optimize a particular objective. Many of these systems employ a control systems based autotuner that operates on a linear model of the application being tuned.…”

Revisiting memory management on virtualized environments

“…In addition, they contain complex sharing patterns and interthread communications. Our evaluations on cloud applications are based on the Sector-Sphere platform [Gu et al 2009], with the datasets from [Chen et al 2012]. The two mapreduce applications are knn [Gillick et al 2006] and ann [Liu et al 2010].…”