LLVM之父，相信有很多人都知道，Chris Lattner。从2000年开始，搞LLVM到现在。LLVM最初的想法还是来自Chris Lattner的导师：Vikram Adve。编译界的大牛。
这篇文章来自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会利用率飙升。本以为中了什么病毒，旁边的程序员大哥嘿嘿一笑，说：电脑在做自动优化。
路漫漫其修远兮，吾将上下而求索！
嗯，看来编译领域大有可为…水非常地深…
@baozii, :-)，要做的东西太多了，人力太有限。所以各个公司才拼命的鼓吹概念，吸引人气，而且往往会一家独大。Intel搞了X86,龙芯累死累活短时间内很难比得上。微软搞了Windows，Linux累死累活也难在市场上取胜。Google做了搜索，其他都拼命赶超，还是不行。
那么ruby和lisp是否能编译成机器码运行以达到c那样的速度呢？jruby已经把ruby编译成了jvm的字节码，但是不知道为什么仍然速度比java慢…
@baozii,
1,理论上是完全可以的，不过需要强大的静态分析的支持，C语言的静态分析优化已经做了好几十年了，再加上C本身的设计贴近机器底层，便于生成高效的汇编码，所以性能很好。关键是Ruby和Lisp这种脚本语言的分析，做的人比较少，每种语言又有自己的特点，所以静态优化一定要每个语言都分析一套。没有太多人顶，速度也就上不去。
2,JVM最初是为JAVA设计的，某些JAVA的语言特性，可以直接设计成高效的实现。相反，Ruby要想在JAVA的地盘上混，就得适合JVM的特点，Ruby本身的一些特性就很难发挥出来，必须用最笨的方法。所以效率也上不去。不过关键还是得看有没有人愿意做这方面的优化，只要深入做，应该也会有提升。 Python也有类似编译机器码的支持，把.py文件编译成.pyc文件，据说执行效率会会有提升。 http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html
我谢谢你才对，建了一个好的技术BLOG分享知识，很多东西在其他地方找不到呢，呵呵，加油~
详细的数据我也找不到，这个领域一直众说纷纭呢，里面水好深，提供一个帖子，我感觉挺好
第一帖是开始时候某个工程师的测试C#和C++的性能比较
http://www.cnblogs.com/wuchang/archive/2006/12/07/584997.html
第二贴是微软的支持工程师对这个测试的分析
http://blog.csdn.net/eparg/archive/2007/09/19/1792013.aspx
我还想问些问题，象RUBY，LISP这样的语言可以把一段输入或许某个数据当做代码来执行，这样的语言特性是不是一定需要强大的运行时系统来支撑呢？为什么RUBY和LISP运行效率不高，是因为它们的语言本性决定的，还仅仅是没有一个好的编译器？它们是否能达到像JAVA和C#那样的运行效率呢？
1,是的，需要运行时支持。通常这种语言被称为解释型语言，包括Python,Perl,Ruby,Lua,Lisp等等，这种语言可以一句一句的执行。通过运行时环境来解释这些代码执行。JavaScript也属于这种语言。
2，运行效率问题，和语言特性有关系，比如弱类型语言(对数据类型的要求不高)就需要运行时来分析类型，并做出相应操作，这个就很耗时，但对程序员来说能提升编程效率。
3，我觉得可以按照执行环境到不同把语言分成三类，一类是纯解释型语言，如各种脚本语言；第二类是Java和C#之类的，虽然语言是编译执行的，但有运行时环境的支持，即编译器把这些源程序编译成某种中间表示，然后运行时环境再像执行脚本语言一样，解释执行中间表示 ;第三类是C之类的静态语言，直接编译生成可执行文件，这种文件可以直接在操作系统中运行。这三类的性能是递增的。脚本语言我觉得不可能达到Java C#的效率(前提是它们的运行时环境使用的优化都差不多),因为Java和C#和脚本语言一样都有运行时环境，可以做投机优化。但同时Java，C#又有静态编译分析过程，可以做复杂的冗余删除。这个Ruby和Lisp做不了。
我一定再接再厉，欢迎多来看看，呵呵。
Ruby和Lisp这种脚本语言的运行时支持，就是解释器，如Python有个Cpython，JavaScript在Firefox中有TraceMonkey，在Chrome中有V8.
博主，为什么现在的托管代码，类似c#和java这样的语言，比原生代码类似c++性能差别已经缩小不到10%呢？它们怎么做到的？未来会不会比原生代码还要快呢？
@baozii,
1,现在是有性能差别变小的趋势，具体的性能差别有多大，我不知道，如果你有详细的数据，能给我出处吗？我也想好好了解一下:).
2,怎么做到的？ 这些托管代码语言，大部分的编译优化都在翻译成托管代码时做过了，但为了某些特性，也做了一些牺牲，这是性能比较差的原因。性能差的缩小，多半来自于运行时支持的改进，如JIT技术，更精确的分支预测等等。
3,会不会比原生代码快？我觉得会，但不能单纯的依靠过去的技术。日后的程序有运行时支持肯定能带来好处。现在基本主流的语言都在发展运行时，C/C++有LLVM，C# F#有CLI,JAVA有JVM， Python和lua这类的就更不用说了，有解释器。但这种性能提升是有前提的，依靠传统的方式肯定不行，但有多核的话，可以用多个核投机，收集运行时信息。再利用这些做优化，那肯定就会有更多的性能上升空间:)
一点拙见，谢谢你的问题，一个好问题。呵呵。
[...] LLVM之爷谈下一代编译器 [...]
>>这并不是说自动并行化将死而复生
啊？？？原来已经公认自动并行化是白费蜡？
@ayaya, 恩，只能启发式的。因为并行化需要对要执行的程序本身有了解。很多并行还需要算法上的改进才行。所以想用并行拿到很高的加速没戏。顶多做做线程方面的投机，都算很牛了。前天听了明尼苏达大学的Antonia Zhai的讲座，她做的就是线程投机，试图将串行程序分裂成并行的线程，在将这些线程放到其他核上运行。基本上，在SPEC CPU 2000标准测试集上，能拿到30%的性能加速就很牛了，而且这还需要硬件有些支持，比如Cache加宽一个bit，硬件增加新的计数器等等。文章 发在去年计算机方面的顶级会议ISCA上，国内现在才发过三四篇的一个会议。 http://portal.acm.org/citation.cfm?doid=1555754.1555812
所以，还是得了解算法，才能并行。编译器只能基于现有程序做，能做好就很牛了。
我觉得目前自动并行化很难做的一个关键因素是语言本身带来的问题，这一点C语言很明显。在基于C的自动并行化过程中，因为有指针别名，函数参数别名等因素导致一个可并行的程序片断如imperfectly loop nest 的数据依赖关系不容易分析出来。如果能够适当降低C语言的灵活性，结合前些年的仿射划分方法，对循环嵌套这种程序片段其实还是可以进行自动并行化的。
语言特性的确即使它的特点，又是它的麻烦。C中的指针即使它最灵活的地方，对做编译的人来讲，也是最头疼的地方。Intel的Ct就是典型的降低C的灵活性。但感觉也不好使。如果放弃了指针，等于说就放弃了C。 不过好在现在高低级语言的层次已经很分明了。C只在关键的应用，提升性能的应用上用的多。面向应用的，对开发速度要求较高的，基本都用更高级点的C#或者JAVA实现了。自动并行化还是需要一个全新的方式来审视计算机结构甚至图灵机的工作模式。这个一般人搞不懂：）
我觉得自动并行化仍然将在编译器优化中占据很重要的位置，虽然目前自动并行化的效果不是很好。未来的自动并行化应该是在很大程度上依赖高级语言的特性了，对计算机体系结构的依赖应该逐渐减小。
除非有新语言和模型诞生，否则以目前的方式，基本自动并行化没戏。要处理的问题很多都是NP完全的，编译器和CPU都搞不定。
比如并行就会牵涉到几个进程同时执行。有了同时执行，就有通信。通信的开销在一两个进程同时执行时还好。几十个上百个时就很麻烦。如果用软件机制通信，太慢。硬件机制虽然快，但通用太难。
再比如，几个进程同时执行，就牵涉到投机。投机就牵涉到投机失败，投机失败就意味着功耗增加。
十几年的研究已经说明，自动并行没戏。