搜文章
推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > 嘻话Tech > 一个IBM, Microsoft, Huawei都关心的软件工程问题

一个IBM, Microsoft, Huawei都关心的软件工程问题

嘻话Tech 2017-11-28


伴随着我2003年加入加拿大多伦多大学,刚从并行化编译器研究转向软件需求工程的研究,可以研究的课题很多,但最让我感兴趣的是能否把改进产品性能的目标转向改进过程效率。


在软件工程里,构造编译是一个不可缺少的环节。任何提高编译效率的方法和工具都应该能够带来立竿见影的效果。


之前我对编译器研究的思路是怎样让程序跑得更快,而现在反过来,是想找到让编译器这个程序跑得更快的方法。所以,第一项任务是如何加快编译速度。


当然,如果要编译的程序很小,即便提高编译速度也不会有太大区别。幸运的是,我找到了和IBM多伦多实验室的合作机会(最著名的DB2数据库管理系统就是在这个实验室开发的),从一开始我们就接触到足够大规模的软件程序。


这个软件程序到底有多大呢?当时是7百万行C/C++程序。现在大家可能不觉得这是一个天文数字,可在当时,编译一遍这些代码需要整整7个小时!


IBM的工程师找到我们,觉得这是一个软件工程的问题。对我来说,这当然也是一个并行化编译的经典问题:第一,程序编译是可以并行化的,每个编译单元相对于其他单元可以独立调用编译器;第二,程序编译是有相关性的,有一些头文件需要是在编译的时候反复引入,导致代码膨胀。


简单地统计一下,这样的情况还真不少。我最早在2003年只用一个月就初步完成了一个经验性的分析,用vim编辑器,一个具有一定代表性的C语言开源软件说明了编译引入头文件带来的性能问题会带来虚假的相关性,也就是我们所说的False Positives1】。接下来,就是实打实地在IBM产品代码上调试。说句题外话,当时我住在多伦多租的地下室,一个人跳灯夜战,感觉颇有些车库创业的感觉。以至于2003北美大停电的时候,我亲身经历过伸手不见五指的黑暗时刻,为我现在开放大学的同事提供了复杂系统需求研究的素材【2】。


话说回来,又是一年过去了,我接连在软件工程会议上发表了两项结果。首先,真实的编译相关性反映的是程序的内涵,由此基础进一步做体系结构的划分,利用Gail Murphyreflexion model,应该能够得到更合理的结果。


这点在我们看到vim的推荐体系结构和滑铁卢大学手工调整的结果比,要更加符合Smalltalk提出的面向对象Model View Controller的编辑器体系结构模式【3】。


这个发现直指Program-in-the-large程序设计的要害。其次,虚假的程序相关性是通过自动规整(restructuring) 加以消除的。这一点听上去理论比较简单,可是在实际工程上需要大量的例外处理。


比如说,C++里面的forward reference是可以避开一些相关性的所谓dirty trick,但是,当这些引用之间形成回路,就好像一团乱麻,难以下手了。其他的问题,比如指针函数,模板带入等等,都是需要逐条解决的。


现在回想起来,我都吃惊自己当时怎样单枪匹马做到的。不过由于专注和目标明确,这个工具很快就产生了效果。


仍旧以vim为例,经过规整以后编译速度提高50%以上不成问题。而在IBM的数据库系统上做测试的效果,把之前7个小时编译时间减少到了2个小时。当然用上并行化和Cache优化后,在8核的工作站集群里面效果进一步提高了30多倍【4】。


接下来,我带着这个工具去找工业界的朋友试用,比如风河,微软,ARM和华为,总结了更多的经验教训。就先说几条吧。


第一,在程序只需要编译一次的时候,规整的时间不可忽略,编译多次则代价会降低。第二,在程序规整的时候,一些相关性分析本身可以认为是轻量级的编译(precompilation), 必须删除不必进行的计算) 


在华为同仁的鼓励下,我做了大胆的尝试,进一步改进了编译器的前端,让这个第一次编译的负荷就小于后段编译的收益,从而总体速度提高了20%5】。


从学术方面看,喜忧参半。由于该技术是工程性为主,所谓理论创新性相对比较小,即便提高了C/C++编译速度,又如何?在二十年前,Smalltalk的编译普渡大学就有人提出过Smarter compilation改进其编译速度,可是工业界用smalltalk的公司不多。虽然C/C++的使用者远远多于Smalltalk, 又如何?


从创新的角度看,这篇论文不是很讨巧,而工作量相对很大,不容易找到志同道合的博士生深入研究这个方向。遇到工程基础不强的学生,我一般也不建议他们选这个课题。好在微软Visual Studio的人最近重新发现了这个需求,申请了相关的专利【6】,侧面证明这是一个有钱途的方向。


当然,20%的速度提高远远不是优化的极限,我的创业团队正在憋一些大招。有兴趣的朋友可以跟我私聊,交换一下看法。


参考文献

1Yijun Yu, Homayoun Dayani-Fard, John Mylopoulos: Removing false code dependencies to speedup software build processes. CASCON 2003: 343-352

2Thein Than Tun, Michael Jackson, Robin C. Laney, Bashar Nuseibeh, Yijun Yu: Are Your Lights Off? Using Problem Frames to Diagnose System Failures. RE 2009: 343-348

3Homayoun Dayani-Fard, Yijun Yu, John Mylopoulos, Periklis Andritsos: Improving the Build Architecture of Legacy C/C++ Software Systems. FASE 2005: 96-110

4Yijun Yu, Homayoun Dayani-Fard, John Mylopoulos, Periklis Andritsos: Reducing Build Time through Precompilations for Evolving Large Software. ICSM 2005: 59-68

5Yijun Yu, Faster Compilation through Lighter Precompilation, The Open University, UK, Technical Report, 2012/07, 2012. pp. 1-5.

6MicrosoftSelective compiling method, device, and corresponding computer program producthttp://www.google.com.gi/patents/US9535672


版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《一个IBM, Microsoft, Huawei都关心的软件工程问题》的版权归原作者「嘻话Tech」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注嘻话Tech微信公众号

嘻话Tech微信公众号:xihuatech

嘻话Tech

手机扫描上方二维码即可关注嘻话Tech微信公众号

嘻话Tech最新文章

精品公众号随机推荐