John Sloan 是 Digital Aggregates Corporation 公司的技术咨询师,他关注超大型和超小型系统,包括分布式,实时、高性能、嵌入式、高度并行系统等多方面。他有一个名为 Chip Overclock 的博客,最近发布了一篇文章——《所有有趣的问题都是扩展性方面的问题》。
John 之前曾在美国国家大气研究中心工作,2006 年时,他绘制了一个图表:
这个图表的横轴是以年为单位的时间,纵轴是技术随时间演变的对数值。John 在 1997 年做了相关的数据挖掘,下面是他的一些假定:
微处理器速度每 2 年翻一倍。
内存密度每 1.5 年翻一倍。
总线速度每 10 年翻一倍。
总线带宽每 5 年翻一倍。
网络连接速度每 1 年翻一倍。
网络带宽每 10 年增加 10 倍。
第二存储密度每 10 年增加 10 倍。
每个微处理器上的 CPU 核每 1.5 年翻一倍。
虽然有些数据已经不再准确了,但是 John 的基本理念没有变:
所有的技术都在变,但是速率不同。这意味着:你之前基于掌握的技术做出了一些技术决策,但是这些决策对于你目前掌握的技术来说可能已经不再正确了。
……
我的经验告诉我:所有有趣的问题都是扩展性方面的问题。这张图展示出了可扩展性的时间因素。
2006 年,John 还展示了一张饼图,列出了软件开发生命周期中的各项成本占比。其中,维护成本占到 67%。也就是说,即使你能消除掉所有初期开发和测试的成本,软件生命周期的成本也只能缩减三分之一。John 还听说:有些要支持上百万行代码的组织认为,67% 还是太低了,有些甚至能达到 80%。
John 提到:
Les Hatton 发现:软件维护可以大概分为三类——修正(修复出问题的代码)、完善(改进某些没有问题的代码,比如提升性能或是降低维护成本)、适应。最后这一类将上述两个图结合在一起。适应性维护是说:因为你不能控制的某些东西发生改变,你必须要改变你的代码。
John 的嵌入式领域工作经验告诉他:他常常碰到适应性维护情况。因为某些厂商常常不再生产某些关键硬件组件,而且没有兼容的可替代品。
而他在企业级服务器端的开发经验也有同样情况。
大量的软件基于商业或开源框架和程序库。你会想要升级到最新版本,因为要修复关键的 bug,或者更新全新特性,因为这会影响你的最终交付时间,可最后却发现:你如此依赖的软件做出了“改进”,提供者调整了它的编程接口!这样的事情就会让产品经理急得像热锅上的蚂蚁。
John 认为,要应对这样的事情,可以从 Arduino 和其 8 位 Atmel megaAVR 微控制器学习。他对比了自己使用的 Mac Mini 和 Freetronics EtherMega 单板,指出:
当我在为 EtherMega 单板编写代码时,我之前编写桌面或者服务器平台的经验,包括如何在时间和空间之间权衡等等,都可以抛出窗外了。举个例子,根据应用情况,如果需要某个值,每次都重新计算可能更好,而不是计算一次然后存储起来,因为在 EtherMega 上,存储字节要远比 CPU 处理周期更为重要。
John 接下来提到:
为嵌入式系统开发软件和为高性能计算或大型分布式平台开发软件,二者需要的技能在很大称度上相同,我不是第一个发现这一点的人。
……
在高性能计算(之前成为超级计算)领域中有个趋势:“重新计算”,而不是“计算然后存储”或者“计算然后传输”。因为纯计算能力的增长要远远超过内存或通讯带宽的增长。为这些微控制器小不点编程,与为大型超级计算机编程,二者之间的相似之处比我们想象的多得多。
给微控制器小不点编写软件,这迫使你严肃对待资源限制,要先考虑时间和空间的权衡,要思考如何向上扩展,更要认真思考如何向下扩展。
最后,John 号召大家都尝试下嵌入式开发:
在我的 Amigo 项目中使用像 Arduino 和 FreeRTOS 这样的技术,让我成为了一个更优秀、更聪明、更能深入思考的软件开发者。我相信你也同样可以从中受益,不管你的问题所在领域及其规模如何。
InfoQ 的读者们,您在自己的项目中是否遇到了类似的问题呢?
评论