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

61–70 of 130 posts

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

#61

Post by Firerouge »

mirashii wrote: post #57
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…

FPGAs are indeed commonly used for SDR as well. Ettus has a range of USRPs with FPGAs on-board, and you can find readily available IP cores for anything from Bluetooth to DVB-S.

That's partially where I got my inspiration.

Seems like it integrated properly it could be a great component in a general purpose PC to future proof it against changing needs and requirements

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

#62

Post by 0xffff2 »

pensono wrote: post #55
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…

FPGA latency is also much more predictable. Since you have cycle level control, you can know exactly how long any given operation will take. In a multi-threaded CPU, it's likely that the operation may be interrupted or delayed because of another process using the same resourt. It's also worth noting that FPGAs are often much closer to the I/O than a CPU on a motherboard. Pin to pin latencies are much reduced in a sit…

>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?

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

#63

Post by namibj »

0xffff2 wrote: post #62
pensono wrote: post #55

Earlier quoted context omitted.

FPGA latency is also much more predictable. Since you have cycle level control, you can know exactly how long any given operation will take. In a multi-threaded CPU, it's likely that the operation may be interrupted or delayed because of another process using the same resourt. It's also worth noting that FPGAs are often much closer to the I/O than a CPU on a motherboard. Pin to pin latencies are much reduced in a sit…

>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?

Not since Ring -1 came to existence.

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

#64

Post by [deleted] »

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…

[deleted]

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

#65

Post by slededit »

jeffreyrogers wrote: post #12
radarsat1 wrote: post #4

Earlier quoted context omitted.

Proprietary and bloated yes, but I believe both Xilinx and Altera both have software available for Linux, or am I wrong? At least I used Altera's suite on Linux once for a pilot project.

I have used Xilinx's toolchain on Linux, though it was hard to get working. This was a few years ago.

They support Ubuntu now. Setup was just as easy as windows for me.

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

#66

Post by TheAdamist »

jaxtellerSoA wrote: post #15

Aren't FPGA's used mostly to test/design a circuit that you would then go on to actually fabricate/build? I could be wrong but I thought FPGA's were stateless (meaning if they powered off/reboot you loose everything and have to set it up from scratch again).

They make it into commercial products, for a recent example see nvidia using it in the gsync modules for 4k displays. Although a retail priced $2600 fpga doesn't make for a cheap end product, even when purchased in quantity.

https://www.pcper.com/reviews/Graphics-Cards/ASUS-ROG-Swift-...

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

#67

Post by tomnipotent »

blacksmythe wrote: post #54
ChuckMcM wrote: post #43

The author isn't aware apparently of over a decade of work done in FPGA/CPU integration. Both in more sequential languages like System C[1] or in extended instruction set computing like the Stretch[2]. Not to mention the Zynq[3] series where the CPU is right there next to the FPGA fabric. For "classic" CPUs (aka x86 cpus with a proprietary frontside bus and southbridge bus) it can be challenging to work an FPGA into…

>> The tricky bit on these systems is how much effort/time it takes >> to move data and context between the "main" CPU and the FPGA and then back again The sweet spot for FPGAs is when the data is streaming. You can build hardware where the data is passed from one stage to another, and doesn't go to RAM at all. Particularly where the data is coming in fast, but with low resolution (huge FPGA advantage for fixed point…

> The sweet spot for FPGAs is when the data is streaming

Netezza does this with their hardware, I've been dreaming of the day I could DIY and put a OSS RDBMS on top.

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

#68

Post by make3 »

Is there a pipeline to compile tensorflow computation graphs to fpga? seems like this is one possible benefit of Tensorflow's fixed graphs, that they may be much easier to compile to fpga then other options

Edit: Seems like some experimental work is being done with XLA (and llvm) https://www.google.ca/amp/s/www.nextplatform.com/2018/07/24/...

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

#69

Post by stefan_ »

0xffff2 wrote: post #62
pensono wrote: post #55

Earlier quoted context omitted.

FPGA latency is also much more predictable. Since you have cycle level control, you can know exactly how long any given operation will take. In a multi-threaded CPU, it's likely that the operation may be interrupted or delayed because of another process using the same resourt. It's also worth noting that FPGAs are often much closer to the I/O than a CPU on a motherboard. Pin to pin latencies are much reduced in a sit…

>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 speculative execution of instructions. Instructions cost variable amount of cycles and take variably long depending on instructions before and after.

And then, with the SoCs that are everywhere now.. you are poking some memory mapped register, say you toggle a GPIO output value.. how long does it take to change on the actual physical pin? Is the GPIO peripheral part of the processor or some IP they bought in and then interconnected over an AXI bus? Is it buffered? It's all entirely impossible to say.

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

#70

Post by zackmorris »

stevesimmons wrote: post #59

Does anyone have experience of Reconfigure.io [1] and their toolchain that transpiles Go for execution on FPGAs [2]? I am curious how it feels from the developer perspective, how it works in practice, and what types of applications it is a good fit for. [1] https://reconfigure.io [2] http://docs.reconfigure.io/overview.html

I've waited 20 years for something like that, thanks for posting! FPGAs are great but I think the biggest problem with them is that they're an array of gates instead of logic units (like ALUs). So the learning curve to get to the point where you can place an array of cores and memories and have them all communicate is so high that most people never get that far.

So that's been a huge barrier to exploring the problem spaces that GPUs are currently used for like AI and physics simulations. Hopefully using languages like Go/Elixer/Erlang/MATLAB/Octave etc will alleviate that to some degree.

My gut feeling is that in 3-5 years we'll reach the limits of what SIMD can accomplish and we'll find it difficult to do the kinds of general-purpose MIMD computing needed to move beyond the basic building blocks of AI like neural nets and genetic algorithms. I stumbled onto these links a month and a half ago and I think something like this will make writing generalized/abstract highly parallelized code tractable again:

http://aggregate.org/MOG/

https://en.wikipedia.org/wiki/Flynn%27s_taxonomy

Original at: https://news.ycombinator.com/item?id=17419917

Post reply on HN