4 ms·

how do these compare to gpus? a kind-of client is considering using this or something similar to process radio data (calculating correlatins i assume) and i'm

how do these compare to gpus? a kind-of client is considering using this or something similar to process radio data (calculating correlatins i assume) and i'm curious what chance i have of selling him a gpu based solution instead.

Cieplak 14y ago
In fact, initially JP Morgan looked at GPUs for acceleration. They ported one of their models to the graphics architecture and were able to get a 14- to 15-fold performance boost. But they thought they could do even better with FPGAs. The problem was that it was going to take about 6 months for an initial port. That's when they went to Maxeler and initiated a proof-of-concept engagement with them. http://www.hpcwire.com/hpcwire/2011-07-13/jp_morgan_buys_into_fpga_supercomputing.html http://www.hpcwire.com/hpcwire/2011-07-13/jp_morgan_buys_int...
- groby_b 14y ago
  Color me skeptical. The FPGA version was basically a rewrite, removing all kinds of OO overhead (objects/classes, templates, etc.) I would not at all be surprised that if that cleaned up code was ported to a GPU, you'd see a much bigger speedup. And if they did this for the GPU code, I'm not quite sure why they needed a consultant to do the same thing before starting to work on FPGA code. I'm not saying the numbers are wrong, but this is certainly insufficient data for any decision :)
  - marshray 14y ago
    GPUs [...] were able to get a 14- to 15-fold performance boost [...] Their Monte Carlo model, for example, was able to realize a 260- to 280-fold speedup using FPGA acceleration. These numbers are consistent with other computations I've seen that were well-suited for FPGAs.
    - groby_b 14y ago
      14x seemed awfully small. Looking at e.g. http://mcx.sourceforge.net/cgi-bin/index.cgi http://mcx.sourceforge.net/cgi-bin/index.cgi, they see a ~300x speedup for a monte carlo simulation on the GPU. (Note - it might well be that the FPGA version of that particular problem would be even faster. I merely posted the GP to point out that there was significantly more effort to tailor the model towards the FPGA than towards the GPU, which seemed to be merely a "compile for GPU" without a restructuring to make the data model fit.)
      - marshray 14y ago
        I've also heard that financial companies needed good double precision support, which was not always fully performant on GPUs.
Symmetry 14y ago
In general when implementing an easily parallelizable algorithm, you can expect about an order of magnitude improvement in power or speed going from a traditional CPU to a DSP or GPU, another going from that to an FPGA, and another going from that to hard silicon. In real applications you often have un-parallelizable or less-parallelizable parts that limit your gains.
al4dev 14y ago
This really depends on the application; but in general FPGAs are a good choice for small to medium volume software defined radio applications, including building correlators and beamformers for radio telescopes (casper.berkeley.edu). CASPER tools used to be a major user of Borph - it made the open hardware and software platforms easy to use to anyone that had experience with Linux; however its use got killed by complexity. The biggest challenge for FPGAs is tools; the CASPER guys used Matlab Simulink; which works OK for small designs, but becomes challenging as the devices and designs grow. There are also a bunch of C to gates tools, Matlab to gates and Haskell inspired tools like Bluespec, and even some Python tools. In fact for the Berkeley CASPER group, as GPU through put improved (along with processing) and the size of the radio telescopes increased, it made sense to move to a hybrid FPGA+GPU backend processor. For fun and training we built an ARM Cortex A8 (with or without GPU and vector processor) + FPGA platform called Rhino (http://www.rhinoplatform.org http://www.rhinoplatform.org), with a couple of FMC IO slots for attaching ADC/DAC/Control etc then ported Borph and then linked up with the Migen project (https://github.com/milkymist/migen https://github.com/milkymist/migen) to "simplify" programming and configuring the FPGA (https://github.com/brandonhamilton/rhino-gateware https://github.com/brandonhamilton/rhino-gateware). We think it works great ;-) We have used it to build a arb. waveform radar transceiver and a few other things. Ofcource now one has the Xilinx Zynq 7K family which includes dual core ARM and tightly coupled Xilinx V7 fabric all on a single chip. Plus for a few hundred $$ you get a nice development board (www.zedboard.org) and a frontend wirless digital receiver FMC card - http://goo.gl/qCnJM http://goo.gl/qCnJM Not sure if that helps...

Cieplak 14y ago

In fact, initially JP Morgan looked at GPUs for acceleration. They ported one of their models to the graphics architecture and were able to get a 14- to 15-fold performance boost. But they thought they could do even better with FPGAs. The problem was that it was going to take about 6 months for an initial port. That's when they went to Maxeler and initiated a proof-of-concept engagement with them. http://www.hpcwire.com/hpcwire/2011-07-13/jp_morgan_buys_into_fpga_supercomputing.html http://www.hpcwire.com/hpcwire/2011-07-13/jp_morgan_buys_int...

groby_b 14y ago
Color me skeptical. The FPGA version was basically a rewrite, removing all kinds of OO overhead (objects/classes, templates, etc.) I would not at all be surprised that if that cleaned up code was ported to a GPU, you'd see a much bigger speedup. And if they did this for the GPU code, I'm not quite sure why they needed a consultant to do the same thing before starting to work on FPGA code. I'm not saying the numbers are wrong, but this is certainly insufficient data for any decision :)
- marshray 14y ago
  GPUs [...] were able to get a 14- to 15-fold performance boost [...] Their Monte Carlo model, for example, was able to realize a 260- to 280-fold speedup using FPGA acceleration. These numbers are consistent with other computations I've seen that were well-suited for FPGAs.
  - groby_b 14y ago
    14x seemed awfully small. Looking at e.g. http://mcx.sourceforge.net/cgi-bin/index.cgi http://mcx.sourceforge.net/cgi-bin/index.cgi, they see a ~300x speedup for a monte carlo simulation on the GPU. (Note - it might well be that the FPGA version of that particular problem would be even faster. I merely posted the GP to point out that there was significantly more effort to tailor the model towards the FPGA than towards the GPU, which seemed to be merely a "compile for GPU" without a restructuring to make the data model fit.)
    - marshray 14y ago
      I've also heard that financial companies needed good double precision support, which was not always fully performant on GPUs.

Symmetry 14y ago

In general when implementing an easily parallelizable algorithm, you can expect about an order of magnitude improvement in power or speed going from a traditional CPU to a DSP or GPU, another going from that to an FPGA, and another going from that to hard silicon. In real applications you often have un-parallelizable or less-parallelizable parts that limit your gains.

al4dev 14y ago

This really depends on the application; but in general FPGAs are a good choice for small to medium volume software defined radio applications, including building correlators and beamformers for radio telescopes (casper.berkeley.edu). CASPER tools used to be a major user of Borph - it made the open hardware and software platforms easy to use to anyone that had experience with Linux; however its use got killed by complexity. The biggest challenge for FPGAs is tools; the CASPER guys used Matlab Simulink; which works OK for small designs, but becomes challenging as the devices and designs grow. There are also a bunch of C to gates tools, Matlab to gates and Haskell inspired tools like Bluespec, and even some Python tools. In fact for the Berkeley CASPER group, as GPU through put improved (along with processing) and the size of the radio telescopes increased, it made sense to move to a hybrid FPGA+GPU backend processor. For fun and training we built an ARM Cortex A8 (with or without GPU and vector processor) + FPGA platform called Rhino (http://www.rhinoplatform.org http://www.rhinoplatform.org), with a couple of FMC IO slots for attaching ADC/DAC/Control etc then ported Borph and then linked up with the Migen project (https://github.com/milkymist/migen https://github.com/milkymist/migen) to "simplify" programming and configuring the FPGA (https://github.com/brandonhamilton/rhino-gateware https://github.com/brandonhamilton/rhino-gateware). We think it works great ;-) We have used it to build a arb. waveform radar transceiver and a few other things. Ofcource now one has the Xilinx Zynq 7K family which includes dual core ARM and tightly coupled Xilinx V7 fabric all on a single chip. Plus for a few hundred $$ you get a nice development board (www.zedboard.org) and a frontend wirless digital receiver FMC card - http://goo.gl/qCnJM http://goo.gl/qCnJM Not sure if that helps...