我正在寻找可靠的参考资料,说明超级计算机在协调和实际任务相关工作上花费了多少资源。资源可能是可用的处理能力,但即使瓦特似乎也是一个有效的单位。
我相信我的一位教授或教科书曾经说过,在大规模并行系统中,多达一半的可用处理能力用于协调任务和消息传递。不幸的是,我似乎找不到这个参考资料或关于这个比例的任何其他材料。
我意识到这将根据超级计算机架构而有很大不同,而现代实现在这方面可能更有效,因此跨多个架构或演进(在专用消息传递硬件之前和之后)对这个指标的概述会更好。
我正在寻找可靠的参考资料,说明超级计算机在协调和实际任务相关工作上花费了多少资源。资源可能是可用的处理能力,但即使瓦特似乎也是一个有效的单位。
我相信我的一位教授或教科书曾经说过,在大规模并行系统中,多达一半的可用处理能力用于协调任务和消息传递。不幸的是,我似乎找不到这个参考资料或关于这个比例的任何其他材料。
我意识到这将根据超级计算机架构而有很大不同,而现代实现在这方面可能更有效,因此跨多个架构或演进(在专用消息传递硬件之前和之后)对这个指标的概述会更好。
长期以来,高性能计算中最受欢迎的基准是 HPLinpack 基准,它测量计算机系统每秒浮点运算的速度,同时求解非常大、密集的线性方程组。假设解采用浮点运算和测试仪被允许改变以达到最佳性能。
基准测量包括 RPEAK(系统每秒的理论最大浮点操作数)和 RMAX(HPLinpack 基准测试中每秒实现的最大操作数。)
RPEAK 通常是 RMAX 的很大一部分,这表明在此基准测试任务中,当前的超级计算机可以实现其理论峰值性能的很大一部分。例如,在 2015 年 11 月的 TOP500 超级计算机排名中,最快的机器天河二号的 RPEAK=54.902 petaflops,RMAX=33.863 petaflops。
然而,HPLinpack 基准测试被广泛认为不能代表当前的工作负载。HPlinpack 结果通常在很大程度上夸大了超级计算机在实际应用中的性能。
一个名为 HPCG 的新基准正在开发中。该基准涉及通常在迭代方法中执行的操作,用于求解由离散 PDE 产生的大型稀疏方程组。对于高性能计算机而言,这种工作负载更具挑战性。它也更能代表超级计算机在实践中的用途。
HPCG 的一些早期结果不到 RPEAK 的 5%。例如,天河 2 号的 RPEAK=54.902 petaflops,HPCG 为 0.58 petaflops(请参阅下面有关 HPCG 的介绍。)
TOP500 HPLinpack 基准测试可以在以下位置找到:
有关 HPCG 的介绍可在以下网址找到:
http://www.hpcg-benchmark.org/downloads/isc15/HPCG-ISC15-FINAL-SLIDES_update1.pdf
HPCG 的网站位于
诚实的答案是我们不知道。答案很大程度上取决于实际运行的内容以及用户编写的代码。正如 Brian Borchers 指出的那样,两个基准测试之间存在很大差异,我们拥有所有代码并且应该知道该代码在做什么,但是对于该代码在多大程度上代表超级计算机用户实际在做什么方面存在很大分歧。如果没有详细的源代码分析和对真实机器上真实代码的大量检测,找到这个比率几乎是不可能的。有一些项目开始收集数据,这些数据可能会让社区接近回答这个问题,但还没有解决。
事实上,这个问题甚至不是很清楚。如果集群节点的通信卡上有一个只能用于通信的处理器,那么如何计算这张卡空闲而不处理通信(也不是其他任何事情)的时间?即,什么算作“可用处理能力”?我们是否将未优化的计算和通信例程与优化后的写得不好的程序相提并论?如果有人在他们的代码中使用了已知的反模式,而故意利用 CPU 不足怎么办?那些根本不通信的令人尴尬的并行程序呢(我向你保证,这些程序确实在超级计算机上运行)?
我不会浪费你的时间试图量化一本书或你的教授的即兴评论。这些类型的陈述提醒我们并行编程很难并且通常做得很差。超级计算机也并非完美地设计用于消除或优化所有浪费。