Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Use an FPGA Instead of a CPU or GPU?

blog.esciencecenter.nl

Post reply on HN
Print view View original

91–100 of 130 posts

Re: Why Use an FPGA Instead of a CPU or GPU?

#91

Post by cjhanks »

neuromantik8086 wrote: post #85

> The HPC community is already used to GPUs — getting people to switch from GPUs to FPGAs requires larger benefits. It's worth pointing out that some scientists haven't even made the leap to CPGPU computing yet and are still relying upon OpenMP / multithreading on general purpose CPUs, even when a GPU would be clearly superior. Anecdotally, I remember hearing that climate science simulations are particularly bad abou…

In my experience, it's true. And it's unlikely to change - the simulation code was largely written in FORTRAN and C over a period of 50 years.

This is in fact what makes Intel Phi so appealing to some.

Re: Why Use an FPGA Instead of a CPU or GPU?

#92

Post by jcranmer »

fpgaminer wrote: post #56
seliopou wrote: post #40

One clarification on the comment about latency. FPGAs are typically clocked much slower than a modern CPU. Typically, they run somewhere in the low 100's of MHz, whereas an Intel CPU clocks in at around 3GHz last time I went to the Apple Store. With a typical x86 multiply instruction having a latency of about, say, 3 cycles, putting that workload on an FPGA would result in a ~10x slow-down! The real benefit of an FPG…

Another thing is that you can pipeline, for example, multiplies. So in a CPU multiply you give the CPU inputs, wait a couple cycles, and then get the result. In an FPGA you can build a pipelined multiply. It's built such that you can feed it input every cycle and get an output every cycle. The only caveat is that the outputs are delayed relative to the inputs. i.e. you may give it (2, 3) to multiply on one cycle, but…

> Another thing is that you can pipeline, for example, multiplies. So in a CPU multiply you give the CPU inputs, wait a couple cycles, and then get the result.

Just to be clear: CPUs will pipeline high-latency execution units. Most arithmetic operations, vector, integer, or floating point, will have a reciprocal throughput of 1 (i.e., you can issue a new operation every cycle) even if their latency will be 3 or 4 cycles. See Agner's optimization tables for actual counts. The major exception to that rule is division, which has a reciprocal throughput of ~5 cycles or so and a latency ~3-4 times that.

Re: Why Use an FPGA Instead of a CPU or GPU?

#93

Post by [deleted] »

fpgaminer wrote: post #56
seliopou wrote: post #40

One clarification on the comment about latency. FPGAs are typically clocked much slower than a modern CPU. Typically, they run somewhere in the low 100's of MHz, whereas an Intel CPU clocks in at around 3GHz last time I went to the Apple Store. With a typical x86 multiply instruction having a latency of about, say, 3 cycles, putting that workload on an FPGA would result in a ~10x slow-down! The real benefit of an FPG…

Another thing is that you can pipeline, for example, multiplies. So in a CPU multiply you give the CPU inputs, wait a couple cycles, and then get the result. In an FPGA you can build a pipelined multiply. It's built such that you can feed it input every cycle and get an output every cycle. The only caveat is that the outputs are delayed relative to the inputs. i.e. you may give it (2, 3) to multiply on one cycle, but…

[deleted]

Re: Why Use an FPGA Instead of a CPU or GPU?

#94

Post by joshvm »

chrisBob wrote: post #58
seliopou wrote: post #40

One clarification on the comment about latency. FPGAs are typically clocked much slower than a modern CPU. Typically, they run somewhere in the low 100's of MHz, whereas an Intel CPU clocks in at around 3GHz last time I went to the Apple Store. With a typical x86 multiply instruction having a latency of about, say, 3 cycles, putting that workload on an FPGA would result in a ~10x slow-down! The real benefit of an FPG…

For large calculations, the magic of an FPGA is in its throughput. Imagine that you have some mess of addition, multiplication, ... The time for the first calculation hardly matters. Even if the FPGA is slower getting through the first calculation that took 100 clock cycles on a CPU vs 10 on an FPGA, what happens on the next clock cycle? The FPGA cranked through an entire second iteration while the CPU is a few steps…

My favourite personal example of this is using a GPU to perform an all-pairs nearest neighbour lookup in an image (for all pixels, find the nearest keypoint). That's something like 2 billion comparisons per image. A decent CPU (parallelised) took minutes to do that, at the time.

By far the simplest solution was to brute force it on a GPU. Probably took longer "single threaded", as there was no optimisation at all, but over O(10e6) pixels with a list of O(10e3) keypoints in shared memory it was basically instant.

It was a great lesson in premature optimisation. I could have spent days tweaking the CPU method with heuristics, sorting the inputs, etc. In the end it was less than 100 lines of OpenCL I think.

Re: Why Use an FPGA Instead of a CPU or GPU?

#96

Post by jrockway »

stefan_ wrote: post #69
0xffff2 wrote: post #62

Earlier quoted context omitted.

>In a multi-threaded CPU, it's likely that the operation may be interrupted or delayed because of another process using the same resourt. If you're considering an FPGA, isn't the alternative likely bare-metal CPU programming? In that case, you have just as much control over thread scheduling as you do over FPGA timing don't you?

Throughput and latency are opposite ends of the same tradeoff. FPGAs enable cycle perfect timing control, while for bare-metal CPU programming.. even if you just have an infinite loop running bare-metal on one CPU, looking at the assembly can't tell you anything about the timing. Modern CPUs have multiple layers of caches with penalties for a miss coming in at hundreds or thousands of cycles. They do parallel and spe…

I feel like people are taking the hybrid approach of having a dedicated microcontroller on the same die as their CPU, like the PRU on TI's ARM chips: http://processors.wiki.ti.com/index.php/PRU-ICSS

This by no means replaces an FPGA, but if you just want your pins to flip and code to run at a predictable interval, this gets you that. (As for reading pins, they have another peripheral on the die that will just timestamp when an event occurs. This is much more consistent than dealing with your OS's interrupt handler, but again, it's no FPGA.)

Re: Why Use an FPGA Instead of a CPU or GPU?

#97

Post by FPGAhacker »

opencl wrote: post #80
baobrien wrote: post #76

Earlier quoted context omitted.

The proprietary bloated toolchains are free to use for lower end to mid range parts, even on Linux.

Yes but as as soon as you hit the limits of i.e. Quartus Lite it's $4k per seat per year. Then another $2k for Modelsim. And another $2k if you want the DSP package, etc.

That's on the super low end of the price spectrum.

Re: Why Use an FPGA Instead of a CPU or GPU?

#98

Post by saagarjha »

Is it just me, or does this article seem like it’s trying really hard to push Intel? For an article about FPGAs, failing to acknowledge the other (major) player in the market-there’s no mention of Xilinx anywhere in the article, while plenty of Intel/Altera-seems disingenuous. Really, the tone just seemed to stick out to me as an subtle advertisement piece; maybe it’s just me?

Re: Why Use an FPGA Instead of a CPU or GPU?

#100

Post by Firerouge »

zymhan wrote: post #88
Firerouge wrote: post #32

I've always thought FPGAs would be perfect to have hardware backed video decoding/encoding that could adapt to new codecs (like vp9) while also being updatable for new performance improving discoveries. It also seemed like it would go well with a generic radio subsystem, so you could compile hardware support for new wireless standards that come out after your hardware did (essentially an fpga sdr). It seems like ther…

Experience seems to show that standardizing on a codec or instruction type is the most likely path. Apple iDevices have had hardware transcoding for video for a couple releases now. You really can't just have an FPGA that you recompile to a different architecture within a split second. They typically require compiling, downloading, and testing the the architecture you're deploying. Until someone comes up with a much…

But isn't that a one time expense?

When a program installs it could compile the hardware acceleration for your platform and test it. Can you not, rather rapidly, directly activate that compiled designs every time you launch the program in the future?

In that same vein, one time compilation for a hardware video decoder when a new codecs is released, and simply loading it when you want to play a video, seems infinitely easier than upgrading your desktop GPU or CPU to one that supports hardware acceleration for a new codec.

Post reply on HN