Hacker News Reader

Comment by vvanders | Hacker News Reader

Not sure how they think FPGAs are going to reduce their "cloud workload". FPGAs are pretty power hungry (aside from lattice) and only work well if you have some unique requirements.

View on HN

Fast cores take exponentially more energy than slow ones. So the solution is to use more slow and simple cores instead. We get more performance per watt that way. On PCs we can use GPU's to make computations in parallel. I guess this is like that, but for servers.

GPUs are often considered "hard to program", let's see how this goes for FPGAs.

Intel suggests we program their GPUs and FPGAs with OpenCL. So, in theory, programming FPGAs could be not much harder than GPUs.

At some point we should be able to code these things in (a subset) of C++. Microsoft has made C++ AMP for GPU programming. Herb Sutter has said it or something similar has a good chance of being standardised in C++ at some point.

Some chatter along those lines:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p006...

Good news then. There is no shortage of speedup when we stop considering all memory being equal.

>Fast cores take exponentially more energy than slow ones

What's your source for this/why does this happen?

From my fuzzy memory:

To make a cpu fast you need to shrink them. To the point that the "wires" in the core are so close together that electrons jump from one another. So there is lots of electrical interference. To overcome this voltage needs to be increased. This takes more power and makes the cpu hotter (which requires cooling).

But dont take my word for it. I did some quick Googling. Maybe you can find some better source and explanation:

https://en.wikipedia.org/wiki/Multi-core_processor#Technical...

"For general-purpose processors, much of the motivation for multi-core processors comes from greatly diminished gains in processor performance from increasing the operating frequency. This is due to three primary factors:

- The memory wall; [...]

- The ILP wall; [...]

- The power wall; the trend of consuming exponentially increasing power with each factorial increase of operating frequency. This increase can be mitigated by "shrinking" the processor by using smaller traces for the same logic. The power wall poses manufacturing, system design and deployment problems that have not been justified in the face of the diminished gains in performance due to the memory wall and ILP wall."

It is very well known that the out of order execution engine of modern cpu cores has a very high power overhead.

https://en.wikipedia.org/wiki/Out-of-order_execution

https://en.wikipedia.org/wiki/Bonnell_%28microarchitecture%2...

Basic logic: as you cram more and more out of order and parallel execution, branch prediction and other advanced techniques in a core, there is a diminishing return. If it weren't, you could create a single core of unlimited computing power.

I don't think it is exponential. Dynamic losses in a gate arise from a couple factors (shoot through, dissipation capacitance) but as far as I know they are a joules per switching event effect which scales linearly with clock.

FPGAs are excellent for parallelizing IO, so if the application involves lots of IO, an FPGA coprocessor will likely reduce power consumption if the CPU delegates IO intensive operations to the FPGA.

Not if you're sitting around waiting for data stored on some DB or distributed file system. FPGAs don't do much to address that. However there are certainly cases where you could design very lean systems where you could win with an FPGA, but my guess is the average developer wont be any better at that than they are on the CPU side developing tight high performance code.

Yup, that's my feeling. We can't even get developers to pay attention to CPU cache lines. I'm very doubtful that your average SW dev could understand how to use FPGAs to their advantage.

Just speed up the database and filesystem with FPGAs ;)

Tell that to Microsoft.

http://www.eetimes.com/document.asp?doc_id=1324372

More information here: http://research.microsoft.com/en-us/projects/catapult/

Because they can accelerate arbitrary algorithms anywhere from a percentage to 50x increase often for a fraction of the energy and clock rate?

I'd guess more so when sequential part is on top tier CPU and accelerator is on its NOC.

Where is this magic FPGA that takes an arbitrary algorithm and accelerates it 50x?

FPGAs have a nice niche for certain applications, and they deserve more prominence, better tooling and widespread use, but they are not magic.

FPGAs are usually very good at accelerating one computing algorithm at a time. Not two. Just one. They'll beat processors unless the operations are an obvious fit for processors (for instance, floating point). I/O is actually a bottleneck in FPGAs.

In practice, most applications require executing plenty of algorithms one after the other, depending on input data, with a lot of glue in between (I/O). FPGAs are terrible at that.

50x isn't unreasonable if you can parallelize and/or pipeline a rigidly-defined process, cutting out as much memory and cache accesses as possible.

With the right programming model, 50x seems very, very reasonable, not even magical. A typical computer does a decently high amount of context-switching and cache-loading.

Yes, of course. Hence why FPGAs are brilliant for stuff like networking equipment, massively parallel coupled with massive low-level IO.

But it doesn't work that way for arbitrary algorithms.

On the contrary, given a capable compiler and/or language, translating algorithms into hardware sounds extremely feasible to me.

It's easy in theory but hard go do well. Most that work pretty well are commercial. Here's the only OSS one I know still getting significant:

http://legup.eecg.utoronto.ca/publications.php

I think then we are in agreement that it is /feasible/, then?

I imagine an FPGA in every chipset would go a long way towards writing the software to put them to practical use, though that may also be wishful thinking on my part.

It was mainly used for algorithms and prototyping ASIC's for most of its existence. The high level tools advertised to software people likewise did that. These days, they have great I/O options too.

Where is it that you were taught to take a part of a quote, turn it into a strawman, and knock that down? My quote said effects range from a percentile (low effect) to 50x. That means it has minimal effect over CPU's on some with 50x on others. Try to stick with what I said, eh?

Also, some algorithms can do over 100x. The good ones are just more likely to get less than that so i left it off. I've seen 10-50x in all kinds of papers, though. And those were academics rather than FPGA pro's.

I think revelation was specifically referring to the word "arbitrary" in your post. That makes it sound like FPGAs can speed up any given algorithm, which is obviously not the case.

Could be misleading to some. The intent for arbitrary was that you could implement any algorithm on them. Whereas, custom hardware is usually fixed and some programmable ones are more limited. Plus, I think you can speed up any algorithm at least a little if putting it on FPGA on more advanced node. Reason being there's no other processing besides the algorithm and it's harder to get GP CPU's that optimal at given process node.

That said, the likes of Intel, AMD, and IBM put so much work into CPU's at most advanced nodes that some sequential algorithms will likely do better on them. Synthesized, amateur FPGA bitstream just can't compete with custom, pro, hard blocks designed for exact purpose.

Yes, they pretty much are magic, for applications that benefit from them. For example, no general-purpose CPU can capture RF data directly from an ADC at multiple gigabytes per second, decimate it, and break it into 1024+ channels in real time. Any general-purpose CPU that could do that would be hopelessly uncompetitive in the marketplace.

How Intel benefits from owning an FPGA company, I'll confess I don't know. Altera must have some awfully valuable IP that Intel needs.

It's like I said: FPGA's are awesome accelerators for all kinds of things, datacenters are already using SOC's doing cores + hard blocks (see Cavium Octeon III), and Intel can possibly capitalize by adding FPGA tech to server CPU's. On top of it, they need years of investment into EDA to make it usable. What Altera already did for them.

With FPGA on-chip, you can offload intensive computations to semi-custom blocks. I/O processing, compression, crypto, fast transactions, data mining, you name it.

Wild guess: perhaps their OpenCL to FPGA compiler. OpenCL is many times easier to program than VHDL.

>percentage to 50x increase

you can do that today going from ruby/js to c

That's a particularly thoughtless comment.

The kinds of things being discussed here (compute heavy algorithms) are typically already accelerated by using high performance native libraries. Think BLAS or OpenCL or CUDA and the Python bindings in Numpy etc.

FPGAs aren't usually going to be much use in business-logic heavy algorithms (which of course are often written in interpreted languages). The performance limits of these are usually set by IO, and in some circumstances FPGAs may help with parts of that (eg, the aforementioned database indexing).

Realistically, increasing use of the new M.2 interface with fast SSDs will make more real-life difference though.

Reply on news.ycombinator.com