微波EDA网,见证研发工程师的成长!
首页 > 硬件设计 > FPGA和CPLD > FPGA是实现绿色搜索技术的关键

FPGA是实现绿色搜索技术的关键

时间:10-18 来源:互联网 点击:
                              大幅度提速

                              为了评估 FPGA 加速型过滤应用的性能,我们进行了一系列实验,将基于 FPGA 的实施方案与采用 C++ 编写的运行于 Altix 之上的优化参考实施方案进行了比较。在比较过程中,我们使用了三个 IR 测试集合(参见表 1):一个是文本检索会议 (TREC) 提供的基准参考集合 TREC Aquaint,还有两个分别是美国专利与商标署 (USPTO) 和欧洲专利署 (EPO) 提供的专利集合。我们选择上述测试集合来评估不同文档长度和大小对过滤时间的影响。

                              表 1——集合统计



                              为了仿真众多不同的过滤器,我们通过选择随机文档并用标题作为请求,随后再选择请求服务器返回的固定数量的文档作为伪相关文档,来为每个测试集合构建配置文件。我们接下来使用返回的文档构建相关性模型,该模型定义了文档集合中每个文档应当匹配(就好像从网络进行流处理一样)的配置文件。配置文件中的文档数量从 1 到 50 不等,可确定增加配置文件的大小(词数和文档数)会对性能有何影响。我们将上述进程重复 30 次,并计算平均处理时间。

                              我们在表 2 和图 5 中对有关结果进行了总结。从表中可以清晰地看出,FPGA 实施方案在速度方面通常比标准实施方案快一个数量级。从图中可以看出,配置文件大小(需要匹配的词数)增加后,标准实施方案变得越来越慢,而 FPGA 实施方案的速度相对保持不变。这是因为 FPGA 实施方案支持配置文件评分的流分线操作,这样无论配置文件大小如何,时延基本保持不变。

                              这些结果清晰表明,FPGA 对加速 IR任务有着巨大的潜力。FPGA 的提速幅度已然相当大(特别对大型配置文件而言尤其明显),而且仍有进一步提高的空间。通过仿真,我们确认 FPGA 算法给一个文档词评分需要两个时钟周期。制约因素为每周期 128 位的 SRAM 存取速度,这需要两个周期才能读取四个配置文件词。如果时钟速度为 100 MHz,则意味着 FPGA 能在 15 秒之内完成整个 EPO 文档集合的评分。当前应用在四个 FPGA 上需要约 8.5 秒,因此原则上我们至少可以让性能再翻一番。

                              差异的原因在于 I/O 流 (streaming I/O):通过主机操作系统设备驱动器可将文档流从用户存储器空间传输至 NUMAlink,这需要直接存储器存取 (DMA) 传输。驱动器可传输流的缓存模块。目前,对所传输模块的大小来说,这一传输并不是以最优的方式实施的,进而导致无法达到最高吞吐量。此外,用独立的线程进行传输排序也能避免传输时延。

                              遇到的问题和吸取的经验

                              这一项目的意义不仅在于它展示了 FPGA 作为信息检索任务加速器的优势,而且还为我们提供了 FPGA 加速系统软硬件要求的重要信息。

                              至主机系统的 I/O 是确保性能的关键:NUMA 存储器与 FPGA 之间的 DMA 机制必须获得 Mitrionics SDK 和 SGI RASClib 的支持。在此前的项目中,我们必须先将数据传输到电路板上的 SRAM 中才能进行处理,但这会严重影响性能,因为数据的载入和结果的卸载会造成非常大的开销。此外,我们也清晰地认识到,IR 任务尤其需要大量的片上和板上存储器,才能实现效率最大化。

                              此外,为了充分使用 FPGA,未来的平台必须具备两个重要特性,一是必需能在 FPGA 之间直接传输数据,二是必需能够关闭主机处理器(或用一个主机处理器控制多个 FPGA)。关闭主机处理器的功能尤其重要:在 Altix 平台上,即便 Itanium 处理器完全处于空闲状态也不能关闭。但是,空闲的 Itanium 处理器的功耗也高达工作状态下所需功耗的 90%。因此,尽管 FPGA 加速的节能效果明显,但我们目前的系统即便在加速器运行过程中主机存储器空闲状态下,其总体节能作用仍然有限。

                              开发 FPGA 加速型系统的另一重要领域就是软件。我们的经验明确反映出,主要的复杂问题在于FPGA 和主机系统之间的接口连接:Mitrion-C 中的实际 FPGA 应用开发效率非常高;采用 Lemur 工具套件构建查询和服务文档的框架也相对容易开发。但是,采用 RASClib 开发连接主机应用和FPGA 接口的代码非常复杂,而且由于并发性问题,还非常难以调试。因而,接口代码的开发占据了绝大部分的开发时间。
                              表 2 —— 性能统计数据





                              图 5 —— 时间(秒)和配置文件中文档数量的对比图

                              FPGA 高级编程的最后一个问题是编译速度。习惯于 C++ 或 Java 等语言的开发人员认为即便应用非常复杂,构建时间也应该比较短。除了最基本的设计之外,当前的 FPGA 工具执行综合以及放置路由工作几乎都需要一整天的时间。非常长的构建时间会严重影响工作效率,因而时间应当缩短到一般性软件构建时间,这样才能使 FPGA 加速更具吸引力。

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top