尼克劳斯·沃思教授是对的。Pascal语言的创建者，结构化编程技术的合著者以及1995年的图灵奖获得者指出：

“降低程序速度比提高计算机速度快得多”

从那时起，该声明就被视为维尔斯定律。它有效地否定了摩尔定律，该定律指出，自1965年以来，处理器中的晶体管数量已增加了一倍。这是Wirth在“ Call for Slim Software”一文中写的：

“大约25年前，交互式文本编辑器只有8000字节，而编译器只有32字节，而他们的现代后代则需要兆字节。所有这些肿的软件都变得更快了吗？不，恰恰相反。如果不是速度快一千倍的硬件，那么现代软件将完全无法使用。”

很难不同意这一点。

肥胖软件

开发现代软件的问题非常严重。沃思指出了一个重要方面：时间。他认为软件过大的主要原因是缺乏开发时间。



今天，软件肥胖的另一个原因是抽象。这是一个更加严重的问题。开发人员从来没有从头开始编写过程序，但这以前从来都不是问题。



Dijkstra和Wirth试图提高代码质量，并开发了结构化编程的概念。他们希望使编程摆脱危机，一段时间以来，编程被视为真正专业人士的真正技能。程序员关心程序的质量，赞赏代码的清晰性和效率。



那些日子已经过去了。



随着Java，Ruby，PHP和Javascript等高级语言的兴起，1995年Wirth撰写文章时，编程变得更加抽象。新语言使编程变得更加容易并且花了很多时间。它们是面向对象的，并捆绑了IDE和垃圾回收之类的东西。



程序员的生活变得越来越容易，但是他们必须付出一切。生活越轻松，思考就越少。在90年代中期左右，程序员停止了对程序质量的思考，开发人员Robin Martin在其文章“ Niklaus Wirth是正确的，这就是问题。”同时，开始广泛使用库，其功能总是远远超出特定程序所必需的。



由于该库不是为某个特定项目构建的，因此它可能具有比实际需要更多的功能。没问题，你说。但是，事情加起来很快。即使是热爱图书馆的人，也不想重新发明轮子。这导致了所谓的依赖地狱。 Nicola Duza用Javascript撰写了有关此问题的文章。



这个问题似乎没什么大不了的，但实际上它比您想象的要严重。例如，尼古拉·杜萨（Nikola Dusa）编写了一个简单的待办事项清单应用程序。它可以在您的浏览器中使用HTML和Javascript运行。您认为它使用了多少个依赖项？ 13,000，十三。千。证明。



数字太疯狂了，但是问题只会越来越严重。创建新库时，每个项目中的依赖项数量也会增加。



这意味着Niklaus Wirth在1995年警告过的问题只会随着时间的推移而变得更加严重。



该怎么办？



罗宾·马丁（Robin Martin）建议，入门是拆分库的一个好方法。与其建立一个尽力而为的大型图书馆，不如创建许多图书馆。



因此，程序员只需选择他真正需要的库，而忽略他将不使用的功能。它不仅自身安装了更少的依赖项，而且所使用的库也将具有更少的依赖项。

摩尔定律的结尾

不幸的是，晶体管的小型化不能永远持续下去，并具有其物理极限。也许摩尔定律迟早会失效。有人说这已经发生了。在过去的十年中，各个处理器内核的时钟速度和功率已经不再像以前那样增长。



虽然埋葬他为时过早。有许多新技术有望取代硅微电子。例如，英特尔，三星和其他公司正在试验基于碳纳米结构（纳米线）的晶体管以及光子芯片。





晶体管的发展。插图：三星



但是一些研究人员采取了不同的方法。他们提出了新的系统编程方法，以极大地提高未来软件的效率。因此，根据尼克劳斯·沃思（Nicklaus Wirth）对节目中肥胖症的观察，无论听起来多么神奇，都有可能通过程序“重启”摩尔定律。但是，如果我们可以扭转这种趋势怎么办？

软件加速技术

最近，《科学》杂志发表了一篇来自麻省理工学院（CSAIL MIT）计算机科学与人工智能实验室的科学家的有趣文章。它们突出了三个优先领域，可以进一步加快计算速度：

• 最好的软件；
  
  
• 新算法；
  
  
• 更优化的硬件。

科学著作的主要作者查尔斯·雷森（Charles Leiserson）证实了软件论文的肥胖。他说，使晶体管小型化的好处是如此之大，以至于数十年来，程序员能够优先考虑使代码更容易编写而不是加快执行速度。效率低下是可以容忍的，因为更快的计算机芯片总是可以弥补软件的肥胖。



“但如今，在机器学习，机器人技术和虚拟现实等领域的进一步发展将需要巨大的计算能力，而微型化将不再提供这种能力，” Leiserson说。 “如果我们想充分利用这些技术的潜力，就必须改变我们的计算方法。”



在软件部分，建议重新考虑使用具有过多功能的库的策略，因为这是效率低下的根源。作者建议专注于主要任务-提高程序执行速度，而不要专注于编写代码。



在许多情况下，性能确实可以提高数千倍，这并不夸张。例如，研究人员列举了两个4096×4096矩阵的乘法。他们从Python的实现开始，这是最流行的高级语言之一。例如，这是Python 2中的四行实现：

for i in xrange(4096):
for j in xrange(4096):
for k in xrange(4096):
C[i][j] += A[i][k] * B[k][j]

该代码包含三个嵌套循环，并且求解算法基于代数中的学校课程。



但是事实证明，这种幼稚的方法对于计算能力而言效率太低。在现代计算机上，它将运行约七个小时，如下表所示。





切换到更高效的编程语言已经极大地提高了代码执行的速度。例如，Java程序的运行速度比Java快10.8倍，而C程序的运行速度比Java快4.4倍。因此，从Python切换到C意味着程序执行速度提高了47倍。



这仅仅是优化的开始。如果在编写代码时考虑到将在其上执行的硬件的特性，则可以将速度再提高1300倍。在此实验中，代码首先在所有18个CPU内核（版本4）上并行运行，然后使用处理器缓存层次结构（版本5），添加了矢量化（版本6），并在版本7中应用了特定的高级矢量扩展（AVX）指令。该代码仅需0.41秒，而不是7个小时，即比原始Python代码快60,000倍。



而且，在AMD FirePro S9150显卡上，相同的代码运行时间仅为70毫秒，比通用处理器上最优化的版本7快5.4倍，比版本1快360,000倍。



在算法方面，研究人员提出了一种三管齐下的方法，其中包括探索新的问题领域，扩展算法并对其进行调整以更好地利用现代硬件。



例如，用于矩阵乘法的Strassen算法再增加10％，可以加快最快的7号代码版本的速度。对于其他问题，新算法可以提供更大的性能提升。例如，下图显示了在1975年至2015年之间解决最大流量问题的算法效率方面取得的进展。每种新算法实际上将计算速度提高了几个数量级，并且在随后的几年中对其进行了进一步优化。





解决具有n = 10 ¹²个顶点和m = n ^11个边的图形上的最大流量问题的算法的效率。



因此，改进算法也有助于以编程方式“模拟”摩尔定律。



最后，在硬件架构方面，研究人员主张优化硬件，以便用更少的晶体管解决问题。优化涉及使用更简单的处理器以及创建适用于特定应用程序的硬件，例如GPU适用于计算机图形。



该研究论文的合著者Tao Schardl说：“针对特定领域量身定制的设备可以提高效率，并使用更少的晶体管，从而使应用程序运行速度提高数十倍或数百倍。” “总的来说，硬件优化将通过在芯片上创建更多区域供并行使用来进一步刺激并行编程。”



并行化的趋势已经显而易见。如图所示，近年来，CPU性能仅由于内核数量的增加而提高。





从1985年到2015年，各个核心以及单核和多核处理器的SPECint性能。基本单元是1985 80386 DX微处理器



对于数据中心运营商而言，即使软件性能的最小改进也可以转化为可观的财务收益。毫不奇怪，谷歌和亚马逊等公司现在正在领导开发自己的专用CPU的计划。最早发布的Google TPU张量（神经）处理器和AWS Graviton芯片正在亚马逊数据中心运行。



随着时间的流逝，其他数据中心的所有者可能会跟随行业领导者，以免在效率方面输给竞争对手。



研究人员写道，过去，通用处理器的爆炸性性能提升限制了专用处理器的开发范围。现在没有这种限制。



研究合著者查尔斯·莱森（Charles Leiserson）教授说：“要想提高生产率，就需要新的工具，编程语言和硬件，以便在考虑速度的情况下实现更高效的设计。” “这还意味着程序员需要更好地了解软件，算法和硬件如何组合在一起，而不是孤立地看待它们。”



另一方面，工程师正在尝试可以进一步提高CPU性能的技术。这些是量子计算，3D布局，超导微电路，神经形态计算，使用石墨烯代替硅等。但是到目前为止，这些技术仍处于实验阶段。



如果CPU性能确实停止增长，那么我们将发现自己处于完全不同的现实中。也许我们真的必须重新考虑我们的编程优先级，汇编专家将物有所值。

---

广告

需要功能强大的服务器？我们公司提供史诗级服务器-具有AMD EPYC CPU，CPU核心频率高达3.4 GHz的虚拟服务器。最高配置将给所有人留下深刻的印象-128个CPU内核，512 GB RAM，4000 GB NVMe。