Hacker News Reader

Comment by rwmj | Hacker News Reader

Red Hat supported a lot of research into this and there's some really interesting stuff, but nothing that is very compelling for commercial use. What uses do you have in mind?

To my mind the more interesting stuff are the PCIe FPGA boards like https://www.xilinx.com/products/boards-and-kits/alveo/u200.h...

One particularly interesting research project was using the FPGA fabric to remap addresses, allowing database tables to be "virtually" rearranged (eg. making a row-major data source into a column-major source for easier searching). https://disc.bu.edu/papers/edbt23-relational-memory https://arxiv.org/pdf/2109.14349.pdf

View on HN

> What uses do you have in mind?

Acceleration of new hashing and cryptographic algorithms, new compression algorithms, new codecs, and many other similar things, without adding special-purpose instructions for them.

Implementation of fast virtual peripherals. Accurate emulation of special-purpose hardware.

Implementation of acceleration modules for well-established software. Imagine if popular libraries or databases or other engines didn't just come with acceleration using SIMD and other instruction sets, they also came with modules loadable on an attached FPGA if you have one.

The problem is that these kind of applications suck for multi-tenant clouds which FPGAs turn out to be poorly suited for (high costs to switch out programs) and are too expensive for the consumer. So the applications are quite niche and limited to traditional use-cases of prototyping ASIC designs rather than actual algorithm accelerators which benefit more from dedicated circuitry/instructions in terms of adoption.

As (very much) a layman I've hoped to see something like dynamic hardware acceleration. Eg for a game that has advanced hair simulation, or 3d sound simulation: reconfigure the fpga and offload the calculations. Maybe even more pedestrian things like fpga driven bullet tragectory physics might be implemented at the game engine level.

More optimistically something along the lines of hands-off offloading, where if the scheduler sees enough of the same type of calculation (e.g sparse matrix multiplication) it can reconfigure the fpga and offload.

I was thinking it would be a good fit for crypto. New algorithms could be implemented with better-than-software performance, constant-time algorithms could be ensured etc.

True.

For instance, SHA-3 is quite slow on x86 CPUs, which, unlike the recent ARM CPUs, do not have any hardware instructions to accelerate it.

If there had been an included FPGA, it would have been easy to implement a very fast SHA-3, as its hardware cost is very low.

I think the problem is this misunderstands what FPGAs are good at. They're actually very bad (or at least painfully slow) at calculations like your examples. GPUs are good at that.

FPGAs excel in parallelizing very simple operations. One example where FPGAs are good is where you might want to look for a specific string in a network packet. Because FPGAs are electronic circuits you can replicate the "match a byte" logic thousands of times and have those comparisons all run in parallel and the results combined with AND & OR gates into a yes/no decision. (I think the HFT crowd do this sort of thing to preclassify network packets before forwarding candidate packets up to software layers to do the full decision making).

> FPGAs excel in parallelizing very simple operations.

I don't think that's a good characterization. FPGA are good at what they end up being programmed for. And in the final analysis, everything a chip does is broken down to simple operation.

The FPGA selling point has always been around perf/W and efficiency with regard to a "set of task". An ASIC will always be faster for a specific task, and CPU will always be faster on average on everything. However, when considering say "compression" or "check-sum" as general class of algorithm, and FPGA with a set of predefined configuration could be better and cheaper.

Good at what they're being programmed for is a bit of tautology.

FPGAs being selected for performance per watt was only a fairly recent phenomenon, when they were deployed on semi large scale as password crackers/cryptocurrency miners.

Their real strength is ultimately real time processing (DSP or networking), with reconfigurability often quite valuable for networking applications. For DSP applications it's usually because a MOQ of custom silicon can't be justified.

FPGAs excel at heterogenous tasks that are branching heavy but only use small amounts of local memory. You can call that simple but those are the bane of CPUs and GPUs.

The moment you are memory heavy the FPGA loses it's edge because CPUs and GPUs are designed around hiding memory latency really well and they overall have higher memory bandwidths.

Anything where you need cycle-perfect timing.

I honestly have more hope for cheap effinix FPGAs driving one of those 5 Gbps FTDI chips to get 400MB/s at a price that doesn't break an arm and a leg. (Custom PCB design for less than 100€)

Reply on news.ycombinator.com