1. 《关于并行貌似正确的废话–串行已经尽力了》
2. 《关于并行貌似正确的废话-程序语言发展的启示》
3. 《关于并行貌似正确的废话-程序员是优秀的管理者》

怎么办？解铃还需系铃人。既然自动的做不了，程序员就需要有并行的头脑，用并行的语言和开发方式，设计，实现。怎么并行？

或许计算机和程序语言的发展史能给我们一些启发。

先说最原始的图灵机，一个执行器，一个纸带，一个指针，一个状态。执行器根据当前状态，指针对应纸袋位置的符号，决定机器的下一个状态。后来有了冯诺依曼结构。纸袋和状态存在存储器中，执行器就是控制器，计算器负责计算下一个状态。我们可以把那时候对计算机的操作看作状态序列的跳转操作。

后来有了操作系统控制作业的输入、控制计算机执行作业、控制计算机输出结果。后来发现输入输出的时候，计算部分在空闲。计算的时候，输入输出空闲。花这么多钱买的噪音这么大的破铁箱子就这点本事？专家们忍不住了，要多任务！于是每个任务在计算机内部被细化为输入输出和计算三个部分。但任务有长有短，还是有空闲，于是多进程系统诞生。每个任务只能在独立的存储区内工作，一个单独的守护进程代替人做调度，谁做完了谁撤，谁在等待，就让谁执行。

后来有了编程语言，程序员使用C语言告诉计算机，你先这么这么做，如果满足这个条件，就从A语句开始往下做。如果不满足走B。然后到C点开始，如果满足条件，就反复执行C到D之间的代码，直到条件不满足。慢慢的，提倡在C语言中不使用Goto，只是函数调用，循环，判断，直线语句解决所有问题。主张重复的功能多写成函数。再后来，程序越来越大，提倡不同功能的函数放到不同的文件中，再后来有了变量，常用库函数，库文件。主张函数和变量的声明，复杂的头文件包含和宏定义放到头文件中。

Unix出现了，Unix的设计理念是模块化。模块化设计和实现至今还影响着我们。每个模块都完成独立的功能，提供清晰的接口。模块之间有依赖关系。将这些模块划分为内核态和用户态，限制权限。

后来有了面向对象语言，C++，C#,JAVA, python，Lua等等，有了类，有了模板，有了例外，有了继承,有了虚函数。一个类封装一类对象，C中的struct只是封装了属性，而C++中的class可以封装针对对象的动作。这个类只能做这些动作，这个类中的某些动作只能在它自己的其他动作中用到(private)。再把一些不同类中的类似操作合并成模板(template)，这几个类的某个动作可以用一个函数来完成。如果除了错，不管你是在什么函数调用，什么类中，只要仍出一个信号告诉某一级的某个运行中的函数说，我出错了，出了什么错。它就能把这个信息输出出来，这样就把错误处理也做了封装。继承和虚函数也一样，封装，然后扩展。

其实我们一直在做的就是封装！把我们不关心的东西通通封装起来，只给出要使用这个东西必须的那部分内容就行了。这是计算机人机交互这几十年进化的永恒主题。让人尽可能简单的使用计算机。

====>

相关文章：

• 关于并行貌似正确的废话-程序员是优秀的管理者
• 关于并行貌似正确的废话–串行已经尽力了
• 探秘CPU性能测试：Spec CPU2000之整点篇
• 小议并行计算
• 《多核编译技术研讨会》记二
• 《多核编译技术研讨会》记一

1. 《关于并行貌似正确的废话–串行已经尽力了》
2. 《关于并行貌似正确的废话-程序语言发展的启示》
3. 《关于并行貌似正确的废话-程序员是优秀的管理者》

在没有革命性的芯片制造技术之前，咱们必须得接受要想快，只能并行！即使出来了新的CPU制造技术，只要有计算，就需要时间，只要有时间需求，人就想要程序跑的越快越好。这是必须的，除了程序员，没有人会享受程序运行的过程。用计算机的人只想要结果！所以性能，将是永恒的主题。

怎么提升性能?咱们从下往上看。

单核CPU已经差不多了，流水线，多发射，延迟槽，超线程，单指令流多数据流(SIMD),能用的技术全都用上了。 频率也不能再升了，访存速度也已经差不多了，卖出去的CPU，一半都是在卖Cache，计算单元占的面积在慢慢变小。于是，我们不得不使用多核，众核。

编译器也很为难，从几十年前开始，吭哧吭哧到现在，能用的招全都用上了，先在汇编里找，不行就在源程序分析中找，有没有公共的子表达式可以删除，有没有常数可以传播。再不行，转SSA形式，找出每个变量在哪儿定义的，在哪儿使用的，有没有多余的定义和使用，有没有可以传播下去的公共子表达式和常数。还觉得不够？过程间并行，要编译的函数，要编译的文件，通通拿过来，搅到一起，在仔细分析！接着，部分冗余删除！在IF条件里面的定义先挪到外面，再对两个分支分别做处理。循环能向量化的向量化，能合并的合并，能展开的展开。能做软流水的软流水。弄了半天，发现寄存器不够用了，于是图着色分配寄存器。几十年就这样过去了，性能有所提升，但不高。一不小心还会出错。明明觉得是个优化，增加之后，发现性能却降了不少。颠倒颠倒做优化的顺序都会给性能和正确性造成很大影响。而且编译时间也会增加不少，搞开发的人不乐意了，哥要写程序，写的过程中，编译一次，你丫要我等十几分钟？！几十年了，静态编译优化做到现在也尽力了。

静态优化不行，用反馈。程序给我，编译器用我的，编出的程序给你运行，收集你使用程序的信息，我再用这些信息决定怎么做优化。优化做了，性能提升了，可是程序输入一变，傻了。性能比不做反馈优化又降了不少。怎么办？投机！我把你的程序拆，编译器拆，不知道怎么拆就使劲做依赖分析，能拆多少拆多少，拆出来的部分，能并行的就并行，增加个运行时支持，拆出来的部分先并行执行着，程序需要的时候，就直接把结果奉上。但是问题又来了，有投机就有失败，有失败就有代价。更何况盲目的投机还会造成cache 污染，存储一致性问题。投机失败的恢复问题。每次投机带来的能耗问题。。。。。

串行皱起眉头，一脸苦涩：大哥，我尽力了，已经不行了！

相关文章：

• 关于并行貌似正确的废话-程序员是优秀的管理者
• 关于并行貌似正确的废话-程序语言发展的启示
• 期待未来-一张趣图
• 探秘CPU性能测试：Spec CPU2000之整点篇
• 前瞻-全时优化和LLVM-1
• 《多核编译技术研讨会》记二

这篇文章来自CGO 2009的Keynote：《The Next Generation of Compilers》，keynote是学术会议上的精彩环节，一般是该领域的最权威学者做主题演讲，演讲的内容是很前瞻，高屋建瓴性质的。

过去的十年里，产品级的编译器在通用处理器上已经使用了许多技术，这些技术都是在编译器研究过程中逐渐成熟的。如基于SSA的优化、指针分析、基于程序行为的优化、链接时跨函数跨文件优化、自动向量化、包含动态语言自适应优化的实时编译。这些技术在可预见的未来将继续存在。那么，未来10年里又会从编译器研究中出现什么新的技术呢？

首先,实时编译和动态优化将被扩展到静态语言中，如C/C++和Fortran。图形应用程序中已经用到了这种技术，如MacOS X OpenGL库和AMD ATI编译器，还有即将应用到通用多核平台中的技术，如RapidMind多核开发平台。

第二，可能也是最意料之中的，编译器仍将在应对多核编程挑战中发挥重要作用。这并不是说自动并行化将死而复生，而是编译器将为并行编程提供两种形式的支持：一是为已知并行程序做优化和代码生成，二是利用交互式的，非最优的并行化技术为已有的代码以半自动化的方式提供并行编程模型。

第三，编译器将在提升程序的安全性和可靠性方面越来越重要。最近几年，许多新的语言和编译技术(如Cyclone、CCured、SAFECode)都试图确保存储绝对安全和健壮的语义操作，而且这些语言和技术甚至都直接针对C/C++语言。产品级的编译器都没有理由不提供这些安全保证，至少也应该为那些对安全敏感的软件提供特殊的安全选项支持。此外，这些支持支持也可以利用一个相比机器码生成更强大的安全和可靠性技术保证的强类型虚拟机来实现。

第四，编译器仍然需要通过更加灵巧的自动调优策略来挖掘优化潜能。这将是在已有编译技术基础上挖掘性能提升的主要动力。

最后，编译器将会采用投机优化的方式来弥补保守的静态分析优化的不足。最近体系结构的研究已经能让硬件机制高效实现此类投机，现在轮到编译器发明新的方式来让硬件支持更加强大的传统优化，或者新的优化了。

短短五段话，概括了现在编译的研究热点，而是未来前进的方向。总结起来就是：动态实时优化、多核并行化辅助、编译器可靠性、编译器自动调优、编译器投机优化。

五年以后，我们可能装个编译器的同时要安装解释器，编程序的过程中还要看着一个小小的服务在一直运行。莫名奇妙的CPU会利用率飙升。本以为中了什么病毒，旁边的程序员大哥嘿嘿一笑，说：电脑在做自动优化。

路漫漫其修远兮，吾将上下而求索！

相关文章：

• 前瞻-全时优化和LLVM-2
• 前瞻- 编译器的bug就不能少点？
• 关于并行貌似正确的废话-程序语言发展的启示
• 关于并行貌似正确的废话-程序员是优秀的管理者
• Google的野心–Native Client+LLVM
• 探秘CPU性能测试：Spec CPU2000之整点篇

Native Client (Nacl) 是Google提出的一种让浏览器直接运行机器码的技术，让Web应用可以从客户机上获得更多的性能，同时又不会引起安全问题。这个技术类似于微软的ActiveX。程序员可以使用C++或者其他语言编写web应用程序，再通过Nacl发布。程序中可以调用一些系统服务中安全的API，如声卡或者图形显示等。Nacl能使用的本地系统调用都是已经规定好的，所以安全性有保证。这篇文章介绍如何使用Native Client。

使用Nacal实现图片编辑和分享的应用

图中，灰色部分是不安全的模块。其中IMC，即Inter-Module Communications，模块间通信.  SRPC，即Simple RPC， 简单的远程过程调用机制。 NPAPI，即Netscape Plugin Application Programming Interface，Netscape插件应用编程接口。

因为安全问题，所以Nacl的运行时环境必须禁止很多有安全隐患的系统调用，因此NaCl更加适用于纯计算，或者计算密集的应用，对于需要创建进程，访问文件系统的，通通都要毙掉。不过像cache一样，可信的存储应该可以进行。Nacl会首先做静态分析，在机器码中，找出不安全的系统调用和不安全的指令，这些都能通过反汇编搞定。但还得有运行时环境来保证模块间的通信，让Nacl模块可以和其他Nacl模块和浏览器交互。还有一个问题，硬件例外的处理。比如算数值时溢出了，段错误了，或者被外部中断，因为Nacl的运行时环境将Nacl模块的运行完全屏蔽，所以没辙，遇到终端会直接终止。

PNaCl-兼容可移植性和性能

有了C++之类的语言保证，NaCl的应用的运行效率就有了保证。但还需要开发者预先跟据指令集的不同，编译得到不同的机器码，再根据访问者的CPU分发相应的机器码。问题可想而知：兼容性，可移植性不好。于是Google 想到了热火朝天的LLVM(关于LLVM：《前瞻-全时优化和LLVM-1》《前瞻-全时优化和LLVM-2》《前瞻-LLVM大事记(2004-2010)》).PNaCl就诞生了。

使用LLVM开发Nacl应用流程

使用LLVM，将C/C++代码转换成LLVM中间表示。然后再将中间表示分发给访问者。避免了针对ISA的编译，又能提升性能。LLVM静态编译和动态执行的透明性又使得PNacl的代码更容易调试。LLVM的前端有可以增加诸如Fortran和Objectiv C之类的语言。有个问题，就是PNaCL得以单文件形式分发，不过幸好LLVM工具链提供了在做过程间优化时生成一个bitcode文件的功能。

PNaCl的执行模型

上图是PNacl的执行模型，Bitcode下载到客户机后，通过llc或者ld转换执行，在Nacl的运行时环境中执行。

PNaCl的未来

Google现在基于LLVM的有两个，unladen-swallow和Nacl。JavaScript会被Nacl替代吗？以后Google会用PNacl的后端来替代JavaScript的解释器V8吗？Python如果能用LLVM做后端，C/C++也能扩展到LLVM，那以后会是怎样？

或许有点多虑，就好像每一种语言刚刚出现的时候，都有人认为它会替代所有现有语言。但发展到今天，还没有哪种语言能一统江湖，安全、性能和可移植性本身就是矛盾的，不能兼顾，只有根据应用的取舍。

PNacl的问题

本来的用意是加快执行速度，现在先做一遍翻译，变成bitcode，再做一遍翻译，编程机器码。性能还有保证吗？这个项目2010年二月才开始。还有很长的路要走。

参考：

1. http://code.google.com/p/unladen-swallow/
2. http://en.wikipedia.org/wiki/JavaScript
3. http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/getting_started.html
4. http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf
5. http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/README.html
6. http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
7. http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html

相关文章：

• 前瞻-LLVM大事记(2004-2010)
• LLVM 2.7 发布
• 期待未来-一张趣图
• 通用微处理中的SIMD指令扩展
• 多面体模型是编译器循环优化的未来吗？
• 前瞻-全时优化和LLVM-2

大肠杆菌和Linux系统的控制网络对比

图片来自《科学松鼠会》，很棒的探索新知的网站：）

生物信息学里把DNA序列看成生物体的操作系统，这张图左侧是大肠杆菌的控制网络，右侧是Linux系统的。

生物体系统本身是非常健壮的，这张图显示，在底层，大肠杆菌有很多层次的供调用资源，因此自恢复能力很强，而我们的计算机系统庞大的上层软件都依赖一个小小的CPU和之上的操作系统内核。

于是，操作系统，编译器中，稍微一个小bug都会导致上层出错，进而整个系统不再可靠。当我们还在抱怨CISC指令系统多么多么复杂，X86指令集和体系结构多么多么混乱，RISC多么多么简洁的时候，有没有想过，简单的系统设计往往意味着健壮性的缺失。我个人非常喜欢简单高效的实现，但我们必须接受一个健壮的系统需要臃肿和冗余的现实。

我们的多核CPU就是实现冗余的契机。又多了一个程序员必须学习并行编程的有利论据！当然也别想着我们的计算机系统能简单的让所有的核都能时刻在我们需要他的时候，对我们的请求快速反应。不需要它时，自觉的自我运行，优化我们计算机中的程序。难！

又或许，所谓的云集算才是真正的冗余保证，云计算系统内部的健壮性又如何保证呢？大量的测试？抑或是继续冗余的CPU和虚拟化技术，最后这些都要回归到那些010101010的bit流，哪里才是回归简洁的地方，就像DNA中的四个碱基一样。 未来太令人期待了！

我们必须要系统健壮起来，只有这样，才能让它更有效率更健壮的运转下去。可靠性设计将会越来越重要。多核，众核，云计算来吧！

PS：现在的多核的核数还远远不够，而且现在的半导体制造技术也很落后。其实8核的CPU在出厂时，至少是有9个以上的核的，因为有成品率问题，到了用户手里时，已经经过检测，只打开了8个核而已。以后咱不超频了，超核！

相关文章：

• 探秘CPU性能测试：Spec CPU2000之整点篇
• 《多核编译技术研讨会》记二
• 认识静态链接库
• 前瞻-LLVM大事记(2004-2010)
• 前瞻-主流处理器中的数据并行支持(SIMD)
• GCC初窥

Standard Performance Evaluation Corporation:标准性能测试协会，一个致力于发布管理计算机性能标准化测试的组织.建立于1988年，会员包括Apple，Dell，IBM，Intel，Microsoft和Sun。Spec的测试例子被光感应用于计算机系统的性能测试中。

SPEC的测试例子是为了测试实际生活中的场景，如SPEC web2005通过并发HTTP请求测试web服务器的性能.SPEC CPU通过多个例子的运行时间长短衡量CPU的性能。SPEC的测试例子都采用平台无关代码编写，以便能使用各种编译器和平台来测试。现在的工业界更是针对SPEC中的测试例子做优化来证明编译器，CPU，web服务器等等的性能提升。

SPEC发布了以下性能测试集：

• SPEC CPU2006/2000用来测试CPU，存储和编译器的性能
• SPEC jms 2007,用于测试JAVA消息服务的性能
• SPEC web 2005 用于测试PHP或者JSP的性能
• SPEC Viewperf，用于测试OpenGL 3D图形系统的性能
• SPEC apc，用于测试给定系统中多个3D交互应用的性能
• SPEC OMP2001 使用OpenMP测试并行系统的性能
• SPEC MPI2007 使用MPI测试并行系统的性能
• SPEC JVM 2008,测试Java Runtime Environment(JAVA运行时环境，JRE)在不同客户和服务器系统上的JAVA性能
• SPEC jAppServer2004, 测试JAVA 2 Enterprise Edition应用服务器的性能
• SPEC jbb2005，同样测试JAVA系统的性能，但测试的是a three-tier client/server system (with emphasis on the middle tier)
• SPEC Mail2001，测试邮件服务器的
  

SPEC CPU 2000：

SPEC CPU 2000是SPEC用于测试CPU，编译器和存储性能的，包括整点CINT2000和浮点CFP2000两部分，选取了常用的一些应用作为测试标准，SPEC PU 2000曾是CPU，编译器和存储研究人员证明自己成果的标准，现在已经被SPEC CPU 2006代替，关于2006，本博以后也将会有文章介绍之，敬请期待。

CINT2000

这是用于整点测试的，测试整点算术的性能，包括编译器，压缩，象棋等程序。具体包括以下几个例子：

• 164.gzip：C语言编写，很流行的数据压缩程序，使用Lempel-Ziv coding(LZ77)作为压缩算法。SPEC中的gzip除了读入集外没有其他文件I/O操作，所有压缩和解压都在主存中进行，方便测试CPU和存储子系统。输入：SPEC中的gzip有五个输入，一个TIFF图像，一个web服务器的log，一个程序二进制文件，一个随机数据和一个源码tar包。每个输入集都使用多个不同的压缩级别压缩解压，每次完成之后都会做输入输出对比。
• 175.vpr:C语言编写，FPGA中的电路定位和路由程序,用于计算机辅助电路设计领域。它自动在一个FPGA芯片上实现技术映射，在算法上属于组合优化类的程序。VPR在电路定位中使用了模拟退火法(simulated annealing),初始的随机定位通过本地的被当前位置的干扰反复修正来提高定位质量，这种方式和金属通过自然冷却来增强韧性比较相似。路由在最内层路由循环使用Dijkstra算法的变种来将一个网中的多个终点连接起来。冲突检测与避免在该最内层算法的上层用于解决不同 电路信号连接超过FPGA内部连接上限的问题。输入：net.in文件提供一个电路网表，包括电路的定位和路由信息，该网表来自MCNC电路公司的benchmark。arch.in文件描述FPGA的架构，也就是电路将要基于的。place.in文件提供电路定位，VPR将用它执行路由。在VPR执行定位时，该文件被屏蔽。输出：place_log.out,route_log.out,route.out,place,out.SPEC将会根据前三个文件判断是否输出正确，第四个文件因为随机数会有不同，所以无法判断。VPR被执行两侧，第一次执行定位，第二次执行路由。
• 176.gcc:C语言编写，C语言优化编译器。该GCC基于GCC 2.7.2.2版本，为摩托罗拉88100处理器生成机器码.该gcc就是一个实际运行的编译器，并开启了很多优化。输入：有5个输入，都是预处理过的C代码，integrate.i和expr.i来自GCC自身，166.i通过并置SPEC int2000中的一个Fortran源文件并使用f2c转换为c代码,200.i以同样的方式产生自SPEC fp2000的200.sixtrack,scilib.i以同样的方式产生自Scilib某个版本中。输出：88100行汇编代码文件.
• 181.mcf:C语言编写，组合优化/单点轮换调度(Single-depot vehicle scheduling),派生自使用单站轮换调度的公共物流应用程序。
• 186.crafty：C语言编写，国际象棋游戏程序。这是一个在64位机上设计的高性能计算机国际象棋程序，在32位机上可以使用long long来表示该数据类型。主要是一个整点程序，大量的逻辑运算。通过配置，能生成不同的搜索集，可以对处理器的整点运算，转移预测和流水线等做测试。输入：搜索5个不同的国际象棋残局，并有不同的搜索深度。输出：由搜索树每一层可能的移动集合组成。
• 197.parser:C，字处理程序。连接语法分析器(Link Grammar Parser)是一个基于连接语法的英语句法分析器。连接语法时英语语法的较早理论。给定一个句子，系统能给它赋予一个词法结构，这个结构是两个词之间被标记的连接。该分析器有大约60000个词表的字典.输入：一个给定的句串，一行一个句子。输出：对给定输入句子的分析结果，保罗一个连接集合，和标号集合。
• 252.eon：C++，计算机可视化。eon是一个基于概率的射线跟踪程序，基于Kajiya 1986 ACM SIGGRAPH会议的论文。它将一定数量的3D射线发射到一个3D多面体中，计算射线和多边形的交点，并通过计算入射光和交点生成新射线。最终的计算结果时一个能在照相机内看到的图片。程序中的计算需求和基本计算机图形学中介绍的传统确定性射线跟踪程序很相似，但是它有较少的存储一致性需求，因为很多在同一个位置生成的随机射线横切3D空间中完全不同的区域.输入：eon渲染一个150×150像素的一把椅子在房间前脚的图片。输入文件通过定义位置，大小，发射率和亮度指定空间中的目标。eon会被运行3遍，每边都渲染相同的场景，只是渲染算法不同，渲染算法包括kajiya,Cook,Rushmeier。输出：三个输出文件是ppm格式的图片分别对应三个算法。
• 253.perlbmk:C,Perl语言解释器。这是一个Perl v5.005_03版本的删减版，删除了很多操作系统相关的特性，并增加了一些第三方的模块，包括MD5 v1.7, MHonArc v2.3.3, IO-stringy v1.205,MailTools v1.11,TimeData v1.08。输入：由四个perl脚本组成，一个email-to-HTML 转换器，占用时间最长；一个spec CPU2000用来对比较输出的diff脚本，一个通过迭代算法寻找合格数字的脚本，一个用于测试伪随机数按照预定顺序生成的脚本。输出分别对应各个输入。
• 254.gap:C，群论，解释器中常用。它实现一个语言和库用于做群论计算。GAP是(Groups,Algorithms和Programming的缩写)。输入：有多个部分，先是标准gab速度测试，通过执行组合函数和库，然后有限域，置换群，子群指数计算的中的测试函数；接着时比较寻找可解群正规化子的算法，最后执行一个所谓的ag-group搜集器，这是解释器的一部分，但其容积还没有被很好的计算出来(?)。输出：以上测试的输出。
• 255.vortex,C,单用户面向对象数据库中事务处理的benchmark。SPEC中的vortex来自完整面向对象数据库程序VORTEx的一个子集。输入和输入数据库的事务都会被转换成一个方案。输入：预先配置用于邮件列表，零件目录表和几何数据的三个方案。
• 256.bzip2：C，压缩。基于Julian Seward的bzip2 v0.1，唯一的不同是SPEC中的bzip2除了输入外，无文件I/O。所有的压缩和解压都在内存中进行。输入，输出都和gzip的相似。
• 300.twolf：C，定位和路由模拟。twolf来自TimberWolfSC定位和全局路由，它被用于创建微处理器产品印刷电路布局的流程中，确定晶体管的位置和组内的全局连接。定位问题是一个排列，穷举法耗时太长，TimberWolfSC程序则使用模拟退火作为启发来找到较优解。有三个输入

以上就是SPEC 2000 CINT的所有例子，包括两个压缩程序(gzip,bzip2)，两个电路设计程序(vpr,twolf),两个编程语言相关程序(gcc,perlbmk),一个组合优化(mcf),一个象棋搜索(crafty),一个词处理(parser),一个计算机图形(eon),一个群论(gap),一个数据库(vortex).

每个程序都有其自己的热点，在实际的编译优化中就可以根据自己的优化，选择合适的例子作为衡量标准。或根据例子的特点做优化。跟SPEC例子死磕的方式做编译优化，是否得当现在还有争议。但目前这可能是唯一可行的路了。因为普适性，原理性的优化几乎已经做完了，除了多面体模型用于循环优化。剩下的一类是机器相关的优化，比如CPU中的特殊指令，SIMD指令等。

编译优化未来的路在何方？并行？异构？还是更精彩的未知？

参考：

http://www.spec.org/cpu2000/CINT2000/

http://en.wikipedia.org/wiki/Standard_Performance_Evaluation_Corporation

相关文章：

• 前瞻-LLVM大事记(2004-2010)
• 《多核编译技术研讨会》记一
• GCC初窥
• 前瞻-拿起SIMD的武器II
• 前瞻-主流处理器中的数据并行支持(SIMD)
• what are base and peak metric in SPEC CPU result?

相关文章：

• 好消息：PLDI 2012极有可能在中国召开
• 走进顶尖大学的计算机科学
• 自动向量化
• 探秘CPU性能测试：Spec CPU2000之整点篇
• 前瞻-LLVM大事记(2004-2010)
• 前瞻- 编译器的bug就不能少点？