不可视的OpenCL和APU芯片驱动加速

深碍√TFBOYSˉ_ 2022-09-19 14:26 170阅读 0赞

AMD认为，加速处理器（APU）将在数据中心有一席之地，它是将CPU和GPU整合在一起而成。它所推动的软件开发工具，更容易在GPU芯片上调度程序，比单独在CPU上运行更快。AMD这一看法让服务器领域的竞争变得更为激烈。

AMD在美国加州圣何塞所举办的APU13开发者峰会上，它是关于服务器的一大主题。该公司还展示一些早期的基准测试结果，证明其APU如何更完美地加速Java应用程序。

AMD刚刚与惠普携手共赢，用该公司的“京都（Kyoto）”皓龙处理器（Opteron）X服务器芯片为其登月1500超大规模服务器制造卡盒式服务器。AMD相信，基于CPU和GPU性能整合的京都（Kyoto）和即将面世的“柏林（Berlin）”皓龙处理器X芯片，能够赢得为像登月这样超大规模机器上服务器的供配。这一切都始于芯片，然后以远远高于软件堆栈给工具的方式工作，将允许应用程序在APU内更透明地从CPU到GPU卸载工作，该公司服务器软件规划总监玛格利特·路易斯（Margaret Lewis）告诉《*EnterpriseTech*》。

下面是京都皓龙处理器X（Kyoto Opteron X）的基本资料和速度：

京都芯片有4个AMD 64位的片上“美洲豹”内核，每个内核有32 KB的L1指令和32 KB的L1数据高速缓存。四核共享2 MB的L2高速缓冲存储器。该芯片有一个片上DDR3内存控制器，它可以以1.6 GHz的速度处理高达32 GB的主内存。（要增加更大的内存，就需要提升内存通道，并因此而提高内存控制器的大小、以及在外部设施和电力使用方面的投入，这就是AMD为什么不这样做的原因。）该芯片有一个八通道的串行总线2.0控制器、一个双端口SATA磁盘控制器、和一个双端口USB控制器。芯片封装在一个名为FT3的组件中，直接焊接在主板上的，而不是插入插槽。

皓龙X1150的GPU协处理器关闭，以2GHz运行；而皓龙X2150的GPU开启，以1.9GHz运行。GPU有128个相同的内核，用在Radeon（镭龙）HD 8000图形芯片上。其速度在双精度浮点运算时每秒虽只有93亿次，但在单精度时每秒高达1540亿次。对大规模的工作量来说——地震资料处理、DNA分析、视频转码、面部识别这四种而言——单精度运算才是关键，所以皓龙X的APU将有其用武之地。特别是考虑到GPU的增量成本。当您从AMD以1000枚单位量购买时，X1150的成本才64美元，而X2150也不过99美元。而128核GPU协处理器的成本只有35美元。虽然1540亿次的单精度没有太大的魅力，不过35美元确实不多哟。事实上，这只不过是一块专为单精度工作量而设计的Nvidia（恩威迪亚）K10 GPU协处理器每十亿次浮点运算单位成本的四分之一左右。一整套登月服务器包含十个机柜，每个机柜45个节点，其单精度浮点性能大致为277万亿次。

关于明年的柏林APU，AMD并没有说得太多，但我们可以假设，无论是CPU还是GPU，都会有更多的魅力。以下是AMD公司关于柏林芯片公开的一些信息：

柏林皓龙X芯片将有四个“蒸汽压路机（Steamroller）”服务器内核，这将比最初为笔记本电脑而设计的美洲豹内核强大得多。每对内核都会有它们自己的L2高速缓冲存储器，而其芯片将提供统一的内存——用AMD的异构系统架构（HSA）法跨越式访问CPU和GPU。虽然AMD没提供精确的资料和速度，据说，柏林芯片将比京都皓龙X芯片高两倍的计算性能和内存容量，将比皓龙6386SE芯片提供高出7.X倍的十亿次浮点运算单位瓦特。柏林芯片将在2014年上半年面世，将为下一代镭龙内核提供足够的舞台，就如 AMD所说的那样，“消除GPU对独立显卡的处理需求”。

柏林有了单一封装的CPU和GPU的所有这些计算能力、以及统一的内存寻址，它的目标计算作业市场将比京都的更大：

路易斯表示，APU将适合于蒙特卡洛（Monte Carlo）和在金融服务公司的其它模拟、以及在石油和天然气公司的地震分析——再说，这二者对单精度的需求都超过了对双精度的需求。在线博彩公司和媒体公司，也就是忙于做视频转码的公司，也都会认真对待京都和柏林芯片，路易斯还说，所有这些将设置Hadoop（分布式计算）集群和NoSQL数据存储，如卡桑德拉（Cassandra）和MongoDB。用在Hadoop或图形上的Mahout（象夫）学习算法，也有望在APU上应用。

要将这些工作量在CPU-GPU混合模式中运行，并不是一件容易的事情，AMD知道这一点。不过一直在与编译商和库制造商合作，以使其更容易。

“京都所处的环境就是OpenCL是个好工具，但是也有个问题一直存在，那就是对群集开发商们来说，用它们来向CPU和OpenCL写入编码，对他们来说就有点像外语了，”路易斯解释说。“他们必须要创建OpenCL内核，而后想出如何将这些内核放进他们传统的程序中。我们一直在做的，就如我们一直在探求柏林那样，寻求我们在工具简易化上能做些什么——直接将GPU注入工具中。我们正在试图做的是，把OpenCL放在开发商已经用的编译器和库的后端。因此，如果开发商用Java编写，那么他们就需要自己能用的Java API，且OpenCL需要遮盖起来。”

下面是服务器开发工具微调中的堆栈，以通过OpenCL更加透明地链接到GPU：

路易斯说，clMath库刚在8月份更新，这样您就可以在适当情况下，把它们推向GPU进行处理。PGI现在有了它的贝塔（第二）C、C ++和Fortran编译器，在贝塔测试中对APU中的GPU进行卸载。PGI工具预计在明年的第一季度全面上市。

对于企业客户，支持在GPU上加速Java是关键—— IBM的Java首席技术官约翰·温铭喏其（John Duimovich）九月在每年一次的Java盛会上所要迫切寻求的东西。温铭喏其展示了关于分类算法的一个基准测试结果，在分类潜伏期调度件中出现48倍的减少，不过这是针对Nvidia的一个GPU，而不是在该GPU上运行。这项特殊的测试是使用项目Aparapi工具，允许对OpenCL转换且在GPU协处理器上运行的Java字节码进行并行组块。如果对AMD和甲骨文（Oracle）共同开发的项目苏门答腊（Project Sumatra）流API添加Java 9虚拟机，Java加速将会更加完善。路易斯说，Aparapi、苏门答腊和HSA的结合，将推动Java加速，而无需更改任何代码。该图表显示了GPU加速Java的演变：

AMD已经运行了它自己的一些初步基准测试，证明了GPU可以加速Java，并分享了第一次的成果。基准是运行在一个四核带Java 7的APU处理器上，Java 7运行在一个N体模拟中，以片上完全单线程模式运行，见以下红线：

N体问题模拟在若干体间的互动，顾名思义，是非常密集的计算。您拥有的处理能力越大，您在体间能模拟的互动数量就越大；更大的计算应该兼容更多的要做模拟的体。在多线程拉姆达（Lambda）表达式中对Java代码加的蓝线，将是明年Java 8的一部分。这种改变可以使N体应用程序运行在多线程模式下，模拟体的数量大约呈2倍增加。另外，苏门答腊的实施，预计在2015年或2016年，取决于您问谁，对AMD的HSA共享给CPU和GPU的虚拟内存，提供同样的模拟，在任何地方都是以7.9到12.3倍的性能加速（按互动模拟数量测算），在任何地方都是以1.35至1.48倍的功率增加。

这些权衡都是Java shops很乐意做出的。