我正在开发一种具有大量 3D 图形计算的产品,在很大程度上是最近点和范围搜索。一些硬件优化会很有用。虽然我对此知之甚少,但我的老板(没有软件经验)提倡 FPGA(因为它可以定制),而我们的初级开发人员则提倡 GPGPU 和 CUDA,因为它便宜、热门和开放。虽然我觉得我对这个问题缺乏判断力,但我相信 CUDA 是要走的路,也是因为我担心灵活性,我们的产品仍在强劲发展中。
那么,换个说法,是否有任何理由选择 FPGA?还是有第三种选择?
我们在 FPGA 和 CUDA 之间做了一些比较。如果您可以真正以 SIMD 方式制定问题并且可以访问合并的内存,那么 CUDA 会大放异彩。如果内存访问未合并 (1) 或者如果您在不同线程中具有不同的控制流,则 GPU 可能会大幅降低其性能,而 FPGA 可能会超越它。另一件事是当您的操作非常小,但您拥有大量操作时。但是你不能(例如由于同步)没有在一个内核的循环中启动它,那么你对 GPU 内核的调用时间就会超过计算时间。
此外,FPGA 的功能可能会更好(取决于您的应用场景,即 GPU 仅在其一直在计算时更便宜(以瓦特/触发器而言))。
当然 FPGA 也有一些缺点:IO 可以是一个(我们这里有一个应用程序,我们需要 70 GB/s,GPU 没问题,但是要将这么多的数据输入 FPGA,对于传统设计,您需要比可用引脚更多的引脚)。另一个缺点是时间和金钱。FPGA 比最好的 GPU 贵得多,而且开发时间非常长。
(1) 从不同线程同时访问内存必须是顺序地址。这有时真的很难实现。
我不久前调查了同样的问题。在与从事 FPGA 工作的人聊天后,我得到了以下信息:
如果你能让 CUDA 为你工作,那它可能是目前最好的选择。它肯定会比 FPGA 更灵活。
其他选项包括来自 ATI 的 Brook,但在发生大事之前,它的采用率不如 CUDA。在那之后,仍然有所有传统的 HPC 选项(x86/PowerPC/Cell 集群),但它们都相当昂贵。
希望有帮助。
我会选择CUDA。
我从事图像处理工作,多年来一直在尝试硬件附加组件。首先我们有 i860,然后是 Transputer,然后是 DSP,然后是 FPGA 和直接编译到硬件。
不可避免的情况是,当硬件板真正调试并可靠并且代码已经移植到它们时 - 常规 CPU 已经先进到击败它们,或者主机架构发生了变化,我们无法使用旧板,或者董事会的制造商破产了。
通过坚持使用 CUDA 之类的东西,您不会被束缚在一个小型的 FPGA 板专业制造商身上。GPU 的性能比 CPU 提高得更快,并且由游戏玩家资助。这是一项主流技术,因此将来可能会与多核 CPU 合并,从而保护您的投资。
这是一个始于 2008 年的旧线程,但最好回顾一下 FPGA 编程从那时起发生的事情: 1. FPGA 中的 C 到门是许多公司的主流开发,与 Verilog/SystemVerilog HDL 相比,它节省了大量时间。在 C to gates 中,系统级设计是困难的部分。2. FPGA 上的 OpenCL 已存在 4 年以上,包括 Microsoft (Asure) 和 Amazon F1 (Ryft API) 的浮点和“云”部署。使用 OpenCL 系统设计相对容易,因为在主机和计算设备之间定义了非常好的内存模型和 API。
软件人员只需要了解一些关于 FPGA 架构的知识,就能够完成 GPU 和 CPU 甚至无法完成的事情,因为它们都是固定硅片并且没有与外界连接的宽带 (100Gb+) 接口。不再可能缩小芯片几何尺寸,也无法在不熔化的情况下从单芯片封装中提取更多热量,因此这看起来像是单封装芯片之路的尽头。我的论点是,未来属于多芯片系统的并行编程,FPGA 有很大的机会领先于游戏。如果您对性能等有疑虑,请查看http://isfpga.org/ 。
基于 FPGA 的解决方案可能比 CUDA 贵得多。
显然这是一个复杂的问题。问题还可能包括单元处理器。对于其他相关问题,可能没有一个答案是正确的。
以我的经验,任何以抽象方式完成的实现,即编译的高级语言与机器级实现,都不可避免地会产生性能成本,尤其是在复杂的算法实现中。FPGA 和任何类型的处理器都是如此。专为实现复杂算法而设计的 FPGA 将比其处理元件通用的 FPGA 性能更好,从而使其在输入控制寄存器、数据 I/O 等方面具有一定程度的可编程性。
另一个 FPGA 性能更高的一般示例是在级联进程中,其中进程的输出成为另一个进程的输入,并且它们不能同时完成。FPGA 中的级联进程很简单,并且可以显着降低内存 I/O 要求,而处理器内存将用于有效地级联两个或多个存在数据依赖关系的进程。
GPU和CPU也是如此。在不考虑高速缓存存储器或主存储器系统的固有性能特征的情况下,在 CPU 上执行以 C 语言实现的算法将不会像已实现的那样执行。当然,不考虑这些性能特征会简化实施。但是以性能为代价。
没有直接使用 GPU 的经验,但知道其固有的内存系统性能问题,它也会受到性能问题的影响。
CUDA 有一个相当丰富的示例代码库和一个SDK,包括一个 BLAS 后端。尝试找到一些与您正在做的事情相似的示例,也许还可以查看GPU Gems系列书籍,以衡量 CUDA 与您的应用程序的匹配程度。我想说的是,从逻辑的角度来看,CUDA 比任何专业的 FPGA 开发工具包更容易使用,而且便宜得多。
有一次,我确实研究了 CUDA 以进行索赔准备金模拟建模。有相当多的系列讲座链接到网站上供学习。在 Windows 上,您需要确保 CUDA 在没有显示器的卡上运行,因为图形子系统有一个看门狗计时器,它可以对运行超过 5 秒的任何进程进行核对。这在 Linux 上不会发生。
任何带有两个 PCI-e x16 插槽的机器都应该支持这一点。我用的是 HP XW9300,你可以很便宜地从 ebay 上买到它。如果这样做,请确保它有两个 CPU(不是一个双核 CPU),因为 PCI-e 插槽位于单独的 Hypertransport 总线上,并且您需要机器中有两个 CPU 才能使两条总线都处于活动状态。
你在部署什么?你的客户是谁?在不知道这些问题的答案的情况下,我不会使用 FPGA,除非你正在构建一个实时系统,并且你的团队中有电气/计算机工程师了解硬件描述语言,例如 VHDL 和 Verilog。它有很多东西,它需要与传统编程不同的思维框架。
我是一名 CUDA 开发人员,在 FPGA:s 方面拥有非常少的经验,但是我一直在尝试找到两者之间的比较。
到目前为止,我得出的结论是:
GPU 具有更高的(可访问的)峰值性能它具有更有利的 FLOP/watt 比率。它更便宜它发展得更快(很快你就会真正拥有一个“真正的”TFLOP 可用)。编程更容易(阅读有关此非个人观点的文章)
请注意,我说的是真实/可访问,以区别于您将在 GPGPU 广告中看到的数字。
但是当您需要对数据进行随机访问时,gpu 并不是更有利。这有望随着具有可选 l1/l2 缓存的新 Nvidia Fermi 架构而改变。
我的 2 美分
FPGA 不会受到那些有软件偏见的人的青睐,因为他们需要学习 HDL 或至少了解 systemC。
对于那些有硬件偏见的人来说,FPGA 将是第一个考虑的选项。
实际上,两者都需要牢牢把握,然后才能做出客观的决定。
OpenCL 旨在同时在 FPGA 和 GPU 上运行,甚至 CUDA 也可以移植到 FPGA。
FPGA 和 GPU 加速器可以一起使用
因此,这不是一个更好或另一个更好的情况。还有关于 CUDA 与 OpenCL 的争论
同样,除非您针对您的特定应用程序进行了优化和基准测试,否则您无法 100% 确定地知道。
由于其商业性质和资源,许多人会选择 CUDA。其他人会选择 openCL,因为它的多功能性。
在最近的 GTC'13 上,许多 HPC 人都同意 CUDA 将继续存在。FGPA 很麻烦,CUDA 越来越成熟,支持 Python/C/C++/ARM.. 不管怎样,这是一个过时的问题
在 CUDA 中编程 GPU 绝对更容易。如果您没有任何使用 HDL 编程 FPGA 的经验,那几乎肯定对您来说是一个太大的挑战,但是您仍然可以使用类似于 CUDA 的 OpenCL 对它们进行编程。然而,它比编程 GPU 更难实现,而且可能更昂贵。
哪个更快?
GPU 运行速度更快,但 FPGA 可以更高效。
GPU 具有以高于 FPGA 所能达到的速度运行的潜力。但仅适用于特别适合的算法。如果算法不是最优的,GPU 会损失很多性能。
另一方面,FPGA 运行速度要慢得多,但您可以实现特定于问题的硬件,这将非常高效并在更短的时间内完成工作。
这有点像用叉子快速吃汤而不是用勺子慢慢吃汤。
两种设备的性能都基于并行化,但各自的方式略有不同。如果算法可以细化成许多块执行相同的操作(关键字:SIMD),GPU 会更快。如果算法可以实现为长流水线,FPGA 会更快。另外,如果你想使用浮点,FPGA 不会很满意 :)
我已经将我的整个硕士论文都献给了这个主题。 使用 OpenCL 在 FPGA 上进行算法加速