完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
有一点非常明确的是，对高性能计算的需求不会很快消失，这是因为应用和系统的性能需求已经达到当前计算机系统所能提供的计算能力极限，迫切需要在未来获得更高的计算能力。如果您需要有说服力的证据，这里有三个不同行业的三个实例：
0
|
|
相关推荐
5个回答
|
|
|
许多形状和大小的多核解决方案
如果您从事设计行业的软件工作，您应该担心吗？您从事的行业会采用新一代的并行编程语言吗？您是否正在评估一种自己必须学习新模式的转变，就像我们在客户端服务器计算、面向对象的编程或线程编程中所做的那样？这些技术起初都比较复杂，但最终我们都实现了。 问题在于我们究竟需要改变什么。适应这种新的多核计算技术是一个学习新编码技术的过程吗？我们是否必须采用新的语言来进行设计验证，以表达我们如何使用所有这些内核？我们是否正在研究如何从根本上改变系统开发的方式？ 操作系统供应商需要率先应对这个新的多核世界。他们确信，对我们已经熟悉的编程模型（线程和对象模型）进行简单添加，这对应用程序员而言已经足够，因而阻止了一场危机。操作系统供应商用对称多处理 (SMP) 回填了处理多个内核的细节，隐藏了处理这些架构所涉及的复杂性。这就是我们如今对于需要高性能计算 (HPC) 的编程行业的看法。 但这可能并不是结局。当编程行业经历这些转变中的其中一个时，似乎总是有大量的新语言。大家还记得 Objective-C，X-windows 编程的开始吗？大家还记得硬件爱好者坚持认为 Verilog（类似于 C 语言的硬件描述语言）或 VHDL（类似于 ADA 的硬件描述语言，非常受硬件设计师的欢迎）才是未来世界的编程方式吗？当然，这是在 MATLAB 及其同类的图形编程语言被人认为它们是未来世界的编程方式之前。 这似乎就像我们处于此类转变的早期阶段一样。处于前沿的开发人员已经走上了某种形式的内在并行取值之路，并且似乎某种形式的并行取值即将到来。这时您会想到 OpenCL™ 或 OpenVX，汽车行业会想到 AutoSAR，HPC 行业会想到 POSIX 线程或 MPI。 编译器行业在过去至少 10 年中一直在研究这一领域。但除了代码可以并行化（如在像素级或图像级重复中）的特殊情况以外，例如任务级并行性 (TLP)、数据级并行性或管道级并行性 (PLP)，还没有要提供的突破 (C++)++。也许它会实现。但遗憾的是，万事俱备只欠东风。您能做些什么？你应该怎么做？要回答这个问题，我们需要更深入地了解多核系统的内部。 |
|
|
|
|
|
同构内核与 SMP
如果研究一下如今大部分系统的实现方式，您会发现，在硬件服务器机架中，每个服务器卡同时携带 CPU 和 GPU 芯片，通过提供某种 SMP 的操作系统进行分层。如果这样的系统能够满足您眼前的问题，的确太棒了。但是请记住，这些 SMP 系统已构建为共享内存系统，仅适用于可以处理共享内存模型的应用。如果您获得的性能无法满足您的需求，您会添加更多内核。对于添加额外内核是否有良好的投资回报 (ROI) 以及您是否为数据中心提供了不必要的加热，人们很少关注。只要添加内核能够解决问题，那么没人关心这个问题。 但如果您将 Linux 作为 SMP 操作系统，则会产生一些使得性能预测（即确定投资回报）难以进行的固有问题。这里有 5 个必须了解或至少说明的具体问题。
|
|
|
|
|
|
真正异构性的开始
SMP 系统中已经存在这些复杂的问题。但如果您打算探索真正的异构计算，比如向架构中添加一个或多个 DSP 以加速信号处理，或为无线应用添加硬核 IP（如快速傅里叶变换 (FFT) 内核或维特比***系统无法实现。每种内核都有自己的操作系统、核心或裸机环境。管理所有这些不同的操作系统以及每个计算基础设施的编码很有挑战性。 获得人们关注的第三种方法是超大规模，即使用一个或多个 FPGA 的架构。有两个方面最常讨论使用池化 FPGA 的问题。其中一个方面是改进特定的网络延迟，其中磁盘访问是应用执行时间的重要组成部分。例如，对网络附加存储设备上的关系数据库进行数百万次数据库访问。添加 OS 抽象的网络文件系统 (NFS) 及其相关的不可预测性，这会影响您预测计算时间的能力。第二个方面包括机器学习或机器推理，利用与 FPGA 中的浮点与定点方法相关的权衡。 |
|
|
|
|
|
由上而下和由下而上
到目前为止，我们已经分别通过由上而下和由下而上的方法了解了这种计算需求。 由上而下的方法包括越来越热门的多个并行取值机制。由下而上的方法包括半导体供应商提供的几种多核架构。实际上，这种自下而上的方法迫使程序员找到与之匹配的自上而下的方法。或者，如果您从由下而上的方法入手，系统程序员通常无法在保持跨架构可移植性的同时轻松地将并行规范绑定到多核架构，而这通常是一个关键要求。无论采用哪种方法，映射过程都很麻烦，有很多手动操作和重复。 例如，如果您将 Linux SMP 作为目标，则必须使用操作系统任务设置直接编写并行代码（例如 P 线程）。这些代码最多可移植到使用相同的操作系统（和版本）的其他平台。鉴于大多数计算环境都倾向于使用 Linux，这不算什么问题，但是采用这种方法排除了使用可能出现的其他操作系统或在真正异构的平台上使用这些代码的可能。 如果系统程序员用 OpenCL 语言编程，他们希望供应商能够支持平***立库，以便真正地比较跨架构的性能和可移植性。但通常情况下，事实并非如此。 即使在我们了解自上而下方法和自下而上方法之间的绑定之前，我们也遗漏了基本的第一步，就开始选择可能的解决方案了。我们缺少明确的标准来衡量不同实现方法的优势，因此在拥有一个完整的原型系统进行测量之前，我们缺少用于预估优势的工具。 每个问题都有自己评估优势的首选标准。例如，成本、吞吐量和延迟这样的系统参数可能是显而易见的。但功耗可能就不是了。在经常采用数百个内核的无线基站中，不同的解决方案可以达到从 40％ 到 60％ 的迥然不同的峰值功耗曲线。这样的差异肯定影响了网络运营商维持的电源类型以及价格。如前所述，汽车多核 ADAS 在运行时的单板耗电量可能在 200 瓦左右。如果系统有多个电路板，这会导致热量问题。但热量主要是平均功率的函数，而不是峰值功率。 不只是系统开发人员面临这些预测问题。平台开发人员也必须了解其架构选择的影响。从自下而上或架构的角度来看，重要的是能够量化每种方法在哪些方面具有优势。我们需要衡量特定解决方案的架构如何增强或减少特定问题的需求。 实施是行为在架构上的体现。因此，评估行为在架构上的实施时，有一些问题需要考虑。您是否在衡量关注的实际参数？系统存在之前，我们要怎样做？您是否可以将解决方案调整为针对关注的参数进行优化？在设计周期中，您获得有用参数预估的时间是否太晚，以致于系统不再适用？是否可以同时优化多个参数，或者您是否冒险让逐渐逼近变成无限回归？是否有办法考虑问题领域的固有限制？ |
|
|
|
|
|
结论
我们看到，在物理实体的推动下，系统开发人员正在越来越深入地使用对称架构和现在的异构多核架构。这些架构反过来对操作系统供应商提出了新的要求，并且正在改变我们捕捉软件设计的方式。但我们的多核系统建模方式并没有改变，我们仍按照原来的方式预测任务映射、内存分配和编码决策对最终系统性能的影响。 这些预测不仅需要理解简单的速度标准，而且需要理解更大范围的属性，包括带宽、平均功率和特定子任务的延迟等。我们的预测需要反映 API 级别下实际发生的情况，即使它应该被应用开发人员隐藏，操作系统活动也可以极大地影响系统行为。由于我们正在制定影响实施基本层面的决策（例如在哪些类型的硬件上执行哪些任务），我们需要在设计过程及早进行准确预测。 总之，我们需要支持早期行为级代码的工具，而非支持优化模块的工具。我们需要这些工具来找出对最终系统性能至关重要但不太明显的因素，这些因素不仅包括传统的代码段分析，还包括任务之间和处理器之间的数据和控制传输，任务之间的接口行为，以及重要的动态功率行为。这些工具正在出现，但是对于这一代的系统设计来说，它们出现的正是时候。 转载：Altera |
|
|
|
|
只有小组成员才能发言，加入小组>>
请问下图大疆lightbridge2遥控器主板电源芯片型号是什么？
4474 浏览 1 评论
使用常见的二极管、三极管和mos做MCU和模组的电平转换电路，但是模组和MCU无法正常通信，为什么？
346浏览 2评论
为了提高USIM卡电路的可靠性和稳定性，在电路设计中须注意的点有哪些？
349浏览 2评论
372浏览 2评论
366浏览 2评论
416浏览 2评论
/7 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
2869
评论
淘帖
10902
