Raced profiles

Raced profiles
复制标题

比赛概况

DOI:
10.1145/1542452.1542460
复制
发表时间:
2009
期刊:
--
影响因子:
--
通讯作者:
Leather H
Leather H
中科院分区:
--
文献类型:
--
作者:
Leather H

文献摘要

相似文献

嵌入式编译中的许多问题都需要根据运行时性能选择一组优化而不是另一组优化。自调优库、迭代编译和机器学习技术都可以比较多个编译后的程序版本。在每一个版本中,程序版本都被计时以确定哪个版本具有最佳性能。程序需要为每个版本运行多次,因为大多数性能测量中存在固有的噪声。运行的次数必须足以比较不同的版本,尽管有噪音,但执行超过这个将浪费时间和精力。编译器编写者必须冒着运行次数太少的风险,可能得到不正确的结果,或者冒着运行次数太多的风险,增加他们的实验时间或减少评估的程序版本的数量。以前的作品选择恒定大小的抽样计划,每个编译版本被执行一个固定的次数,而不考虑噪声的水平,在本文中,我们开发了一个连续的抽样计划,可以自动适应实验,使编译器作家可以有信心的结果,也可以肯定,没有更多的运行比需要。我们表明,我们的系统是能够正确地确定最佳的优化设置与76%和87%之间的运行比需要一个蛮力,恒定的采样大小的方法。我们还将我们的方法与JavaSTATS(10)进行了比较;我们需要的运行次数比它少了77%到89%。
Many problems in embedded compilation require one set of optimizations to be selected over another based on run time performance. Self-tuned libraries, iterative compilation and machine learning techniques all compare multiple compiled program versions. In each, program versions are timed to determine which has the best performance.The program needs to be run multiple times for each version because there is noise inherent in most performance measurements. The number of runs must be enough to compare different versions, despite the noise, but executing more than this will waste time and energy. The compiler writer must either risk taking too few runs, potentially getting incorrect results, or taking too many runs increasing the time for their experiments or reducing the number of program versions evaluated. Prior works choose constant size sampling plans where each compiled version is executed a fixed number of times without regard to the level of noise.In this paper we develop a sequential sampling plan which can automatically adapt to the experiment so that the compiler writer can have both confidence in the results and also be sure that no more runs were taken than were needed. We show that our system is able to correctly determine the best optimization settings with between 76% and 87% fewer runs than needed by a brute force, constant sampling size approach. We also compare our approach to JavaSTATS(10); we needed 77% to 89% fewer runs than it needed.