Category Archives: 编译前沿

介绍最新提出的一些编译技术，思想和方法。包括与此相关的语言扩展及分析处理

关于并行貌似正确的废话–串行已经尽力了

Posted on 2010/06/12 by erlv

《关于并行貌似正确的废话》系列文章： 《关于并行貌似正确的废话–串行已经尽力了》 《关于并行貌似正确的废话-程序语言发展的启示》 《关于并行貌似正确的废话-程序员是优秀的管理者》 在没有革命性的芯片制造技术之前，咱们必须得接受要想快，只能并行！即使出来了新的CPU制造技术，只要有计算，就需要时间，只要有时间需求，人就想要程序跑的越快越好。这是必须的，除了程序员，没有人会享受程序运行的过程。用计算机的人只想要结果！所以性能，将是永恒的主题。 怎么提升性能?咱们从下往上看。

Posted in 编译前沿, 编译技术 | Tagged , , , , , , , | 15 Comments

LLVM之爷谈下一代编译器

Posted on 2010/06/03 by erlv

LLVM之父，相信有很多人都知道，Chris Lattner。从2000年开始，搞LLVM到现在。LLVM最初的想法还是来自Chris Lattner的导师：Vikram Adve。编译界的大牛。 这篇文章来自CGO 2009的Keynote：《The Next Generation of Compilers》，keynote是学术会议上的精彩环节，一般是该领域的最权威学者做主题演讲，演讲的内容是很前瞻，高屋建瓴性质的。

Posted in 编译前沿, 编译技术 | Tagged , , , , | 16 Comments

Google的野心–Native Client+LLVM

Posted on 2010/06/02 by erlv

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

Posted in 编译前沿, 编译技术 | Tagged , , , , , , , , | 9 Comments

期待未来-一张趣图

Posted on 2010/05/07 by erlv

先看图 图片来自《科学松鼠会》，很棒的探索新知的网站：） 生物信息学里把DNA序列看成生物体的操作系统，这张图左侧是大肠杆菌的控制网络，右侧是Linux系统的。

Posted in 编译前沿, 编译技术 | Tagged , , , , , , , , , | 7 Comments

前瞻-LLVM大事记(2004-2010)

Posted on 2010/04/30 by erlv

因为之前的两篇博文前瞻-全时优化和LLVM-1和前瞻-全时优化和LLVM-2都是基于Chris Lattner 2004年发表在CGO的文章写的。所以需要介绍一下LLVM从2004到2010这六年的变化，LLVM的开发社区很活跃。 从2004年三月到2010年4月，LLVM共发布了1.2-1.9，2.0-2.7，16个版本，至少每年发布两个版本。详细的历史发布版本和release都能从这里找到。

Posted in LLVM, 编译前沿, 编译技术 | Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 8 Comments

前瞻-全时优化和LLVM-2

Posted on 2010/04/29 by erlv

上篇文章，以论文为主要依据，介绍了LLVM的概况和中间表示，本篇关注论文的后半部分内容–架构设计和LLVM的整体评测： LLVM的架构设计： 总览 LLVM的架构设计以让传统的链接时，安装时，运行时和空闲时代码转换都能透明地在LLVM中间表示上展开为目的。上图就是LLVM的高层设计架构。包括静态的编译器前端用于生成LLVM中间表示；连接器用于做连接时优化，尤其是过程间优化。连接器的输出被JIT或者机器代码生成器生成机器代码。在机器代码生成时，可以通过插入低代价的抽样指令来测量运行时的profile，检测热代码，并将空闲时进行优化。

Posted in LLVM, 编译前沿, 编译技术, 编译理论实践和应用 | Tagged , , , , , , , , , , , , , , , , | 3 Comments

探秘CPU性能测试：Spec CPU2000之整点篇

Posted on 2010/04/14 by erlv

概览SPEC 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应用服务器的性能 … Continue reading →

Posted in 编译前沿, 编译技术, 编译理论实践和应用 | Tagged , , , , , , , , , , , , , , , , | 2 Comments

前瞻-全时优化和LLVM-1

Posted on 2010/04/07 by erlv

读论文<LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation> CGO 04 1，写在前面的话 全时优化(LifeLong Optimization)对于每个编译爱好者来说，太有魅力了。我在起初也是被这个题目所吸引打算一探究竟。本文是04年LLVM的最早两位开发者Chris Lattner和Vikram Adve所写，发表在04年的CGO上， 先来说说LLVM的历史。2000年LLVM开始开发，2005年Apple雇了Chris Lattner，LLVM也相当于成了Apple的官方支持的编译器。Apple已经将它用在OpenCL的流水线优化，Xcode已经能使用llvm-gcc编译代码。可以说05年之前LLVM一直都是学术界的东西，05年之后用于工业界.而这篇文章写在04年.本博最近听过一个关于LLVM的讨论会，会中有资深人士提到LLVM现在越来越像一个普通的编译器。说这番话的意思是，我们可以从这篇文章里找到LLVM的架构设计和早期的一些实现思想，但请不要迷信LLVM现在有多么神奇，每个架构都会有它的优缺点。 这篇文章，我现在已经读完了理论和介绍部分，性能评测部分还没有读。所以标题里面加了个1，因为接下来，还想作几件事，一是读完文章，二是跟踪一下Chris Lattner最近几年的文章，三是尝试将Open64和LLVM做个对比，最后看看代码。所以敬请期待之后的系列文章。

Posted in LLVM, 编译前沿, 编译技术, 编译理论实践和应用 | Tagged , , , , , , , , , , , , , , , , , , | 3 Comments

前瞻- 编译器的bug就不能少点？

Posted on 2010/01/17 by erlv

读PLDI 04 Best Paper Award 《Automatically Proving the Correctness of Compiler Optimizations》 By Sorin Lerner.Todd Millstein and Craig Chambers in Washington U 本博自从接触编译器到现在,几乎都每天都能听到bug这个关键字,编译器中的bug很痛苦,首先,人写的程序很复杂,编译器设计者很难想出所有的情况并一并处理之;其次,编译器的bug很难调,要先排除程序本身的错,接着需要知道到底是分析时出错还是变换时出错;还有这些错都是在怎样的分析和变换中出了错;最后还要担心错误会不会越不越多,没有对编译器整体的理解,很难给编译器打上正确的补丁,从而有可能这个例子补对了,其他又错了一片. 作者在文章里就编译优化正确性的自动证明做了一些尝试,这些尝试在读完文章之后觉得很了不起,只是这里面提到的工作做下来,也是需要很大的积累和投入.作者的尝试我概括如下:将优化分为转换和具体优化两个部分.代码的转换是所有优化都要做的,而并非所有的转换都是优化,所以作者通过增加利益驱动模块来判断某个转换是否是优化,这样优化的自动证明问题,就变成了某个转换正确性的自动证明问题;正确性的定义:转换前后的语义保持不变.接着作者按照转换依据的信息来自转换语句之前还是之后,将转换分成两种模式,即前向转换模式和后向转换模式.然后分别对这两种模式进行讨论,而自动证明也分别针对这两种模式来论述.

Posted in 算法和计算理论, 编译前沿, 编译技术 | Tagged , , , , , , , , , , , , , | 7 Comments