Intel CEO正在阅读的文章。。。

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




Looking Back on the Language and Hardware Revolutions: Measured Power, Performance, and Scaling
Hadi Esmaeilzadeh1,  Ting Cao2,  Xi Yang2,  Stephen Blackburn2,  Kathryn McKinley1
1The University of Texas at Austin, 2Australian National University

点击这里下载 阅读 final-asplos021

Abstract:

This paper reports and analyzes measured chip power and perfor-mance on five process technology generations executing 61 diversebenchmarks with a rigorous methodology. We measure representa-tive Intel IA32 processors with technologies ranging from 130nmto 32nm while they execute sequential and parallel benchmarkswritten in native and managed languages. During this period, hard-ware and software changed substantially: (1) hardware vendors de-livered chip multiprocessors instead of uniprocessors, and indepen-dently (2) software developers increasingly chose managed lan-guages instead of native languages. This quantitative data revealsthe extent of some known and previously unobserved hardware andsoftware trends.    Two themes emerge. (I) Workload: The power, performance,and energy trends of native workloads do not approximate managedworkloads. For example, (a) the SPEC CPU2006 native benchmarkson the i7 (45) and i5 (32) draw significantly less power than managedor scalable native benchmarks; and (b) managed runtimes exploitparallelism even when running single-threaded applications. Theresults recommend architects always include native and managedworkloads to design and evaluate energy efficient designs. (II) Ar-chitecture: Clock scaling, microarchitecture, simultaneous multi-threading, and chip multiprocessors each elicit a huge variety ofprocessor power, performance, and energy responses. This varietyand the difficulty of obtaining power measurements recommendsexposing on-chip power meters and when possible structure spe-cific power meters for cores, caches, and other structures. Just ashardware event counters provide a quantitative grounding for per-formance innovations, power meters are necessary for optimizingenergy.

很高兴有一篇paper进到了ASPLOS (ASPLOS 是Architecture, programming language, operating system 结合领域的最好会议)。虽然我是Co-author,但也从这个paper里边学到了很多东西。这篇paper其实是我们去年在ISCA一个workshop上发的一篇论文的后续工作(H. Esmaeilzadeh, S. M. Blackburn, X. Yang, and K. S. McKinley, “Power and Performance of Native and Java Benchmarks on 130nm to 32nm Process Technologies,” in Sixth Annual Workshop on Modeling, Benchmarking and Simulation, MoBS 2010, Saint-Malo, France, 2010 http://users.cecs.anu.edu.au/~steveb/downloads/pdf/javavc-mobs-2010.pdf)

目前我在ANU读Master. 我自己的research领域是内存管理,大概想法就是在Run-time (JVM) 层面,把application的语义带进系统。一些paper在review过程,最后结果出来后我会在这写总结。 功耗是我RA部分的工作。 这两篇文章最开始的时候挺好玩。我记得最早的时候是 Hadi (这个系列文章的一作) 有一篇讨论 Dark silicon 的文章,然后我们开会一起讨论。在文章里边有一些是基于TDP或者模型的功耗计算, 我觉得基于模型的完全没有意义,建议测量真正的功耗。Hadi的文章里边讨论了power density 随着工艺变化对系统的影响。 印象中我在 linux symposium 看过一篇测量CPU功耗的文章。然后检查ATX的specification, 主板上4个pin的口是给CPU专门供电的,这样我们只需要一个电流计就可以测量CPU的功耗了。我当时奇怪的是为什么在学术界用类似的方法去测量功耗的很少,大部分是无意义的模型。再加上我们实验室正好有一些不同工艺和不同微结构的PC机。同时老板们是 managed language领域的专家。  那去从功耗的角度,不同工艺不同微结构对native language 写的 benchmark 和 managed language 写的 benchmark 的影响显然是我们关心的一个问题。然后就开始了漫漫测量路。

这是一篇测量文章,或者说是一个抛砖引玉的文章。所有的数据大家都可以访问,每个人的背景不同,看到的和想到的也不同。在ASPLOS review的过程中,有的reviewer 给了非常高的分数,但也得到了非常低的分数。文章接受以后,量化的两位作者对这个论文非常感兴趣,他们也给了我们很多很好的建议。 Dave 让他的一个学生用 data mining 的办法去评估体系结构不同的变化对系统的影响 (Mining火啊,看看Zhou Yuanyuan的文章)。 John 则对 SMT 的 power efficiency 非常感兴趣。 其他成员在和 两位牛人讨论的时候我正好在国内,非常遗憾的错过了这个机会。不过从邮件里边还是看到了两个大牛的风采,思路非常清晰。很多公司也对这个paper很感兴趣。IBM 和 Intel 都很喜欢并且邀请老板去讲了一下。我其实很不解的是难道Intel 或者 IBM 内部没有做过这样的分析?

我想再强调一遍,这是一个抛砖引玉的文章。借用文章里边的一句话 Measurement is key to understanding and optimization.

我总结一下这篇文章我个人的一些想法:

*这个论文讨论的是硬件的变化。但是如果把硬件的变化当成一个镜子。镜子里边就是软件的行为。可以说软件对CPU资源的利用是非常非常差的。这个里边充满了机会。比如说double cache, 性能基本没什么变化。 Yale Patt, 曾经说“CPU厂家实在不好意思再加大cache了”。 其实这句话反过来就是 “你们作软件的怎么这么垃圾!!“。 但是这里边机会多多!!!

*Managed language workload 的重要性。他们一般都有一个run-time system 作 Jit, 内存管理,和 其他的一些管理工作。 即便是single thread 的 managed language applications 也能够在多核下得到加速。同时 run-time system 对功耗,性能的影响非常大。CPU厂家应该重视起来这部分。目前就小道消息,硬件厂商内部貌似队这些理解不是很深刻。

*软件对功耗的影响非常大。比如同样的Java application, 不同的 JVM,跑出来的 performance, power, energy 差距非常大。目前CPU还没有一个类似performance counter  的东西帮助软件优化。

*对功耗决定性作用的其实是工艺。但是把成本考虑进来以后就不好说了。

*Energy efficiency 的 SMT。 ARM 貌似调侃过 P4年代的 SMT。 但是我们的结果显示从 energy & power efficiency 角度, SMT 是非常好的。这也许是 Intel 把 SMT 又高回来的原因。当然,想在 SMT 下边获得非常好的性能还是需要考虑很多 resource contention 的问题。

*强大的 Tick-Tock. Tock的时候尝试新的微结构,利用尽可能多的transistor,性能, power都上去 然后 Tick 的时候 die shrinking,功耗会下来,成品率会上去,可以提高频率。 这个基本就跟一个战车一样。 你说ARM能来 高端市场和 intel 打拼一下? 我看现在根本没有机会。

*引入多核的一个重要的原因是功耗。 打个比方,同样推高一个core frequency 20%, 不如两个Core 同时推高5%。这是其实是不得不走多核的一个非常重要的原因。

有兴趣的读着可以下载数据自己分析。

严重感谢首席,没有您多年来的指导和鼓励,我根本不可能懂 architecture, operating system, compiler! 感谢CLF上边前辈门留下的只言片语。比如首席当年没提过L4, V总当年没提过RTEMS,我本科的毕业设计也不会去作 RTEMS ON L4。


(6个打分, 平均:4.33 / 5)

雁过留声

“Intel CEO正在阅读的文章。。。”有21个回复

  1. 陈怀临 于 2011-01-20 6:22 下午

    “ Measurement is key to understanding and optimization. ”

    把握系统的精华。。。!这也是我现在到处强调的:量化,只有量化一个系统,你才能把握一个系统。

  2. Will Chie 于 2011-01-20 7:01 下午

    终于等到了coder的大作。

  3. James 于 2011-01-20 8:06 下午

    最近在看 The pentium chronicles, 里面也很强调了数据的作用. 没有数据的debut 是没有任何意思的

  4. James 于 2011-01-20 8:06 下午

    Sorry, 笔误… 是debate ….

  5. tom.lai 于 2011-01-20 8:58 下午

    只能慢慢细读了

  6. Guancheng 于 2011-01-20 9:18 下午

    我组里面测试功耗也直接用的电流计,个人也认为不基于真实数据再怎么做分析都是虚的。随着功耗重要性的增加,基于CPU中PMC的测试手段会越来越重要。

  7. newer 于 2011-01-20 10:20 下午

    一个地方没看懂:“打个比方,同样推高一个core frequency 20%, 不如两个Core 同时推高5%”。

    先声名,我是门外汉。。。

    假设一个core功耗是1,推高20%是1.2吗?
    两个core是2吗?推高%5是2.1吗?
    可是 2.1 > 1.2 啊,这个要怎么理解?
    还是说其实2个core也是1?

  8. 徐鹤军 于 2011-01-20 10:29 下午

    “*引入多核的一个重要的原因是功耗。 打个比方,同样推高一个core frequency 20%, 不如两个Core 同时推高5%。这是其实是不得不走多核的一个非常重要的原因。”
    看到这条信息,更有信心了

  9. coder 于 2011-01-20 10:32 下午
  10. will.huang 于 2011-01-20 10:57 下午

    功耗是现在处理发展的一个主要瓶颈,作为研究功耗方面的研究者,深表惭愧,研究了那么多年,还是停滞不前

  11. 0xff 于 2011-01-20 11:07 下午

    功耗在现在半导体材料中想大幅度降低很难,我想以后研发出新的类半导体材料,集成芯片,也许功耗降低会有个突破。

  12. newer 于 2011-01-20 11:12 下午

    谢谢 coder

    我在文章里看到两点:
    1. performance 与 power 的增长是非线性关系,这是双核功耗更低的原因;
    2. 这个结果是基于实验的,不知道他的base是什么。从理论上讲,performance在什么一个level比power增长得快呢?这个临界点在哪里? 或者说,给定一个performance, 设计成多少个core功耗最小?我不是要数值,我也不懂,我是想问这个有结论了吗?

  13. 房地产商 于 2011-01-21 12:01 上午

    Intel发展制程工艺和核心架构,但是多core功耗降低不是很明显。

    ARM 嵌入式RISC微处理器占据了低功耗、低成本和高性能的嵌入式系统应用领域的领先地位。嵌入式系统应用可以说是未来发展方向,应用为王。ARM高端市场和 intel PK一下,也不是没有可能。
    建议首席这篇文章标题改改,《Intel CEO正在阅读的文章。。。》,Intel CEO能咋的?还正在阅读,别太个人崇拜。
    我以前做过芯片设计,现在改行房地产开发,对IT真厌倦了。

  14. tutu 于 2011-01-21 7:46 上午

    这里有一家公司解决了功耗问题
    They developed a new technology that can break the so called “Memory Wall”, which will greatly increase the performance of CPU and decrease power consumption by half.
    http://www.ucompower.com/

  15. Alpha StrongARM XScale 于 2011-01-21 1:59 下午

    To 房地产商,
    I encourage you don’t give up the IT; the coming battles/ wars in IT field will be more fun than you see the movie series of “RED CLIFF” and Intel CEO 还正在阅读… looking for ARM’s Achilles heel.
    But ARM also keep presses force on x86 的”罩门”– ARM/Intel多是有一个软肋为对手所攻击.

    有一个成语吗,道高一尺,魔高一丈; ARM/INTC who’s the 魔 or 道? Very interesting!

  16. jebtang 于 2011-01-21 11:00 下午

    coder,希望了解一下你们的四种应用的分类在虚拟机上也适用吗?主要是这四种应用pattern如果在虚拟机上跑,底层的CPU的pattern还保持一致or not? 从理论上讲一讲吧。

  17. coder 于 2011-01-22 6:07 下午

    其实 Java 和 Native 的主要区别就在于 Java 的 run-time 部分。 如果把虚拟机引入,其实又引入了一个run-time system. 对功耗等等的影响就要看你用的什么样的虚拟化方案 和 benchmark 对这个 run-time system 的反应。 我觉得还是要 measure 你们常用的 application 在你们给定系统上的行为。

  18. kernelchina 于 2011-01-23 2:29 上午

    有了这个数据,能发展出来什么应用?能够针对特定应用优化功耗?

  19. Yuhao 于 2011-01-23 5:56 下午

    这学期选了McKinley的memory management的课,会读到这篇paper,到时候再来向诸位高人请教。

  20. coder 于 2011-01-25 3:09 上午

    News: 这个paper会成为下一版体系结构红宝书的一章,不过可能是在光盘上 :-(

  21. coder 于 2011-05-29 8:50 下午