端到端思维在系统设计中的重要性

我年轻时曾参加过松冈洋子的一次演讲--事实上，我太年轻了，以至于我不记得演讲是在什么时候、在哪里进行的。但我记得的是她讲述了设计假手的故事。尽管她之前的设计中设计师们如此执着于创造每一个可能的机械自由度，以至于当插入手部关节和操纵手所需的所有电缆时，由于缺乏机动空间，这只手不仅失去了应有的自由度，而且也没有空间让微控制器真正控制它。因此，在她之前的设计中，设计师们致力于创造每一个可能的机械自由度，以至于当插入手的关节和所有操纵手所需的电缆时，这只手不仅失去了应有的自由度，因为缺乏机动空间，而且也没有空间让微控制器真正控制它。因此，自由度在身体上是存在的，但在功能上是不能操作的。另一方面，她决心设计一只功能最大的手，从而以一种更端到端的方式来考虑设计。从那以后，这件轶事就一直伴随着我。

在我们的计算机体系结构领域，我偶尔会遇到错过端到端画面的建议。我有一次看到有人提出了一个方案，该方案通过跟踪历史来进行未来预测。这些实验涉及跟踪2个、3个或4个历史样本，并使用存储的历史的平均来进行预测。虽然图表显示历史为3的结果最好，因此，这个人推荐了一个3的历史记录，然后将这些值的总和除以3来形成预测。这是一个缺乏端到端思维的最好例子-3对2或4的历史的边际改进不可能超过仅仅为了整个系统中的这个预测器而实施除法器的需要-与移位器相比，面积和功率的影响显然是错误的答案-但只有在你看端到端而不是只看图表中的结果的情况下。

这里的紧张之处在于，随着系统变得越来越大，我们不可能一直考虑整个系统端到端。在微软的Azure，我们在全球60多个地区运营数据中心，其中包括160多个数据中心，这些数据中心由160多个连接在一起的数据中心组成，这些数据中心分布在不同的地区，并由地球上最大的网络之一连接起来。在这个巨大的全球系统的背景下，很难考虑这里的处理器部件可能会做什么。那么处理器架构师应该做什么呢？当端到端系统非常多时，人们如何考虑要解决的各种问题呢？比手头的提案更宽泛的抽象的很多层次？

以下是我评估一个想法价值的小贴士，特别是当整个系统的细节可能被模糊的时候(即，理解整个事情超出了你的薪酬等级)。

考虑一下管道中相邻的步骤。你知道那些相邻的步骤是什么吗？他们在做什么？在这个最小限度扩大的考虑范围中，你提出的事情有什么意义吗？示例：我希望移到4宽的执行阶段，而不是1宽的执行阶段，因为现在您可以多执行4倍的指令。

但是实际上：如果你的FETCH阶段仍然是1宽的，那么去4宽的执行是没有任何帮助的。这不是端到端的思考。

考虑堆栈中的邻接层-RTL、电路或布局设计人员会告诉您出城吗？编译器编写人员会让您走出办公室吗？您的建议在整个开发管道的上下文中有什么意义吗？例如：我想推荐这个新的小部件，它将意味着跨越多个大型结构的通信需要很长的线路。

但实际上：如果你的新设计意味着芯片上有很长的距离，你要么必须放弃周期，因为你必须在那些长线的中间放置触发器，要么需要巨大的驱动器晶体管来推动信号通过线，这会耗费你的电力和面积，或者两者兼而有之。

考虑下1个(或2个)包含的子系统，比如它如何适应整个处理器甚至SoC。我的父亲是一名集成电路设计师出身的建筑师，他有一次告诉我，年轻的时候他从事寄存器堆的工作，他把制作有史以来最小、最省电的寄存器堆作为自己的使命。

但实际上：整个设计中用于寄存器堆的物理面积比他想出来的要大得多，所以实际上，他最终还是要耗电，因为必须通过空的空间从他的插槽边缘布线到他微小的RF的端口。

想想顶层系统的目标。换句话说，多年来，计算机架构师一直认为处理器本身是顶层系统，目标是通过规范尖叫。我们偶尔会偷看一下HPC，那里的系统是处理器和连接它们的网络的集合。但现在，我们坚定地生活在这样一个世界里，世界上的大部分计算机即使不是在由微软这样的超级计算器运营的巨大数据中心集合中，也不明显我们的社区已经完全吸收了这种影响。在这个世界上，我们的大部分计算机即使不是在由微软这样的超级计算器运营的巨大数据中心集合中，也不明显已经完全吸收了这一点的影响。在这个大得多的系统中，处理器只是一个很小的参与者，在这个系统中，除了性能或功耗之外，还有其他非常重要的指标(尽管两者仍然很重要)。

在这个世界上，处理器是一个大得多的系统的参与者，我的建议是考虑提案是否会让平台变得更好。例如：

它是否更安全？您的新环境管理技术是否支持来自共享同一平台的多个客户的工作负载，无论从数据和/或性能角度看，他们的工作负载都是安全的吗？

它能减少尾部延迟吗？可预测的性能在数据中心环境中很重要。我们希望避免这样的场景：云客户向云提供商大量提供相同价格的实例，运行特征测试以找出哪些实例运行在速度更快的机器上，或者哪些实例与利用率较低的邻居共存，并杀死那些没有优势的实例。您的新调度机制是否无论线程位于同一位置，都能实现一致的性能吗？

它是否使虚拟化变得更容易？？一些企业客户希望将其整个工作负载从他们控制的数据中心(即虚拟化)移到云环境中，这意味着在虚拟化环境之上运行虚拟化环境。您的新地址转换方案如何促进这一点？

它是否提高了网络性能(即它能否更好地参与更广泛的平台)？您的新网络卸载引擎是否降低了在主机处理器上处理网络数据包的开销？

它能否提高平台的可调试性或可用性？您的新调试机制是否减少了对在实验室中复制可能需要数百万或数小时才能遇到的模糊错误的依赖？您的新方案是否启用了主机操作系统的安全补丁，同时最大限度地减少了对来宾VM的中断？

当处理器不再是要设计的顶层系统时，尽管性能和能力仍然很重要，但在可管理性、安全性、可调试性和可用性等度量指标方面对更大的系统的改进价值也应该是最重要的。更一般地说，当设计任何系统时，架构师理应向上、向下、向左、向右并弹出几个级别，以确保考虑到端到端的影响。我们不想像盲人与大象的故事一样-摸着鼻子，宣布大象的形状像蛇。

关于作者：Lisa Hsu是微软Azure Compute小组的首席工程师，致力于数据中心部署的战略计划。

免责声明：这些帖子是由个人撰稿人撰写的，以分享他们对今日计算机体系结构博客的看法，以造福于社区。本博客中所代表的任何观点或观点均为个人观点，仅属于博客作者，不代表ACM SIGARCH或其上级组织ACM的观点或观点。