|
注:以下讨论我在暑期讨论组读过的一篇文章,作者们来自微软,主要是从计算机架构上对一些新的尝试,刚刚被ISCA会议接收,是一篇新鲜出炉的文章。我觉得挺有意思,在此分享我的看法,希望抛砖引玉。如有错漏之处,望请指正。
文章: Putnam et al. “A Reconfigurable Fabric for Accelerating Large-Scale Datacenter Services”, ISCA 2014,
链接:http://research.microsoft.com/pubs/212001/Catapult_ISCA_2014.pdf
这项研究主要用的是FPGA阵列来对 Bing 搜索进行加速。作者设计方案是:在每台服务器的PICe接口连接一个FPGA板。一个Rack有48台服务器,相应地,一个Rack需要48个FPGA。在逻辑上,这些FPGA间是直接互联的,但不用服务器的ethernet, 它们有自己的二级网络。48个FPGA组成一个6x8的二维的拓扑结构。每个FPGA都配置有一个8G的DDR3 RAM, 为什么需要RAM的理由在以下讨论。
为了尽量少地改变原有的服务器架构,作者们选择将FPGA连在每台服务器的PCIe上,服务器CPU与FPGA的通信先经过南桥,然后经过PCIe线。之所以不是用其他方法,例如北桥上开一个通道,直接与RAM相联,就是为了最小限度地保持原有架构,这样对服务器的生产也方便(作者还有一点没说,这样的设计也让实验做起来方便,因为他们不用专门去定制48台server, 在原来的上面改就好了)。
但这样的设计有两个缺点:a. FPGA和CPU间的数据传输速度会受到限制,PCIe 有带宽限制,一般PCIe 2.0 的峰值是5Gb/s, PCIe 3.0 是8Gb/s, 而FPGA间的互联网络速度都能达到 20Gb/s, 貌似PCIe 会成为瓶颈。但在bing 搜索的workload里影响不大,因为数据传输量并不大,从服务器传到到FPGA也就是一个个64Kb的文件,PCIe 也能满足需求; b. FPGA 所在的是IO空间(也就是在南桥southbridge上),作者们并不想让FPGA 直接通过DMA去访问内存,因为这样会导致与CPU和其他部件对 memory bus 的争夺, 而是在FPGA另加了一块8G内存,用来放FPGA的临时数据。
这种设计的前提是,问题已经被充分定义和分解好的,分解成一个个适合FPGA运行的任务,让它们可以pipelined。这在Bing搜索这种应用里是可行的,因为它已经明确定义好了一系列骤:feature extraction -> free-form expression -> compression -> scoring, 与Map-Reduce后的处理有点类似。本来这些步骤都是在单个处理器里的微型流水线(pipeline)里完成的,但是这条流水线分到了一个个FGPA里,变成了一条macro-pipeline. 之所以用macro-pipeline能加快速度,是因为这些任务的性质是属于 MISD (multiple instruction, single data) 类型,单个处理器里反复对一个相同的数据进行操作,也就只能用一条垂直的pipeline, 指令是序列化的,而用macro-pipeline就可以实现instruction -level parallelism,是水平方向的并行,效率自然大大提高。
文章标题说的 reconfigurability 其实不太准确,它实际的意思是,写好一些程序逻辑(在bing 搜索里,他们称之为model),放在每个FPGA的buffer里,然后实时地根据query的不同,把不同的model 载入每个FPGA里去。但是,FPGA 的底层运行程序还是事先写好的,所以微软雇了一堆精通FPGA的程序员,花了几个月把FPGA的程序调好,这也就是为何本文有24位作者的缘故。
然而,这种模式在实际产品中行得通吗?要FPGA 产商为每个人企业用户定制他们的程序逻辑,这恐怕不太现实,只能是企业自家来写这方面的程序。无论哪种方式,是对开发者和产品调试来说,要维护FPGA上的应用程序逻辑是一件麻烦事。例如,Bing搜索每更新一次搜索算法,在FPGA上面跑的models也要更新,这恐怕得费一番力气太行。
从效率上上说,在Bing搜索上的应用还算可观的,有95%的加速,意味着你只要新增一个FPGA阵列,就能达到新增48台服务器同样的加速效果,成本大大降低。问题在于这种方案的通用性,以及FPGA上程序的可维护性。
Archiver|手机版|科学网 ( 京ICP备07017567号-12 )
GMT+8, 2024-9-1 17:26
Powered by ScienceNet.cn
Copyright © 2007- 中国科学报社