标签归档:学术前沿

关于并行貌似正确的废话-程序语言发展的启示

《关于并行貌似正确的废话》系列文章: 《关于并行貌似正确的废话–串行已经尽力了》 《关于并行貌似正确的废话-程序语言发展的启示》 《关于并行貌似正确的废话-程序员是优秀的管理者》 怎么办?解铃还需系铃人。既然自动的做不了,程序员就需要有并行的头脑,用并行的语言和开发方式,设计,实现。怎么并行? 或许计算机和程序语言的发展史能给我们一些启发。

发表在 编译前沿, 编译技术 | 标签为 , , , , , | 8 条评论

LLVM之爷谈下一代编译器

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

发表在 编译前沿, 编译技术 | 标签为 , , , , | 16 条评论

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

概览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应用服务器的性能 … 继续阅读

发表在 编译前沿, 编译技术, 编译理论实践和应用 | 标签为 , , , , , , , , , , , , , , , , | 一条评论

计算机系统结构方向的顶尖会议

注,这份表格并非本人整理,来自wwxu的邮件。 会议 会议全称 领域 William & Mary 列表 -2008 新加坡国立 列表 -1999 复旦列表-2008 篇均引用次数 大陆发表情况 3年投稿意愿 Abstract Deadline Full Paper Deadline Notification of decision 1. ASPLOS Architectural Support for Programming Languages and Operating Systems 体系结构 操作系统 编译技术 A+ Rank1 Rank1 … 继续阅读

发表在 编译技术 | 标签为 , , , , , , , , | 留下评论

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

读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很难调,要先排除程序本身的错,接着需要知道到底是分析时出错还是变换时出错;还有这些错都是在怎样的分析和变换中出了错;最后还要担心错误会不会越不越多,没有对编译器整体的理解,很难给编译器打上正确的补丁,从而有可能这个例子补对了,其他又错了一片. 作者在文章里就编译优化正确性的自动证明做了一些尝试,这些尝试在读完文章之后觉得很了不起,只是这里面提到的工作做下来,也是需要很大的积累和投入.作者的尝试我概括如下:将优化分为转换和具体优化两个部分.代码的转换是所有优化都要做的,而并非所有的转换都是优化,所以作者通过增加利益驱动模块来判断某个转换是否是优化,这样优化的自动证明问题,就变成了某个转换正确性的自动证明问题;正确性的定义:转换前后的语义保持不变.接着作者按照转换依据的信息来自转换语句之前还是之后,将转换分成两种模式,即前向转换模式和后向转换模式.然后分别对这两种模式进行讨论,而自动证明也分别针对这两种模式来论述.

发表在 算法和计算理论, 编译前沿, 编译技术 | 标签为 , , , , , , , , , , , , , | 7 条评论