4 ms·

> [when] FPGA adoption becomes sufficiently popular, it gets dedicated hardware instead. I always thought this too, but turn around time (time to market) in ha

by irq-1 9y ago

> [when] FPGA adoption becomes sufficiently popular, it gets dedicated hardware instead. I always thought this too, but turn around time (time to market) in hardware isn't fast enough, and as the article argues, Intel has a vested interest in adding instructions. Most large companies are motivated to add complexity and keep the users spending their time on the companies projects. It doesn't pay to make simpler products that might become commodities. Examples that I don't think would move from FPGA to CPU: - Specialized algorithims that don't have enough users. - Changing algorithims: encryption, HTTP2 parser, data structure/index scanning - Tied to specific software: a game that's popular, but not enough to justify CPU instructions - Portable FPGA: imagine an M.2 or USB style connection fast enough to run an add-on FPGA. It could be the start of making a reconfigurable computer; just add the chips for your software.

rjsw 9y ago
Interfacing FPGAs to PCI or PCIe isn't hard, there are plenty of dev boards available to let you add whatever you want. The ARM+FPGA chips work well too, the IO blocks are decoupled enough from the CPU that you can add your own offload engines.
jerf 9y ago
Then you fall off the other end of the scale: You don't have enough people clamoring for hardware acceleration of this whose needs aren't met by some already-existing plugin card or something. You aren't left with a niche of people who are making decisions about what CPU to buy based on what FPGAs they have, as a group, with sufficiently similar enough specs that they look like a single market to Intel or a chip maker. (That is, someone who just wants "a couple of instructions" and someone who wants "an FPGA for parsing HTTP2 requests" are dissimilar enough not to be the same thing.) In this case, being able to name a multiplicity of very edge use cases isn't an advantage; it is another reason why it doesn't happen. You need one big use that enough people agree on that it's economical to centralize it into the CPU, not a ton of scattered ones with radically different implications in terms of die size, how the data flows in and out, what percentage of users are using it, etc. In fact, in your use cases, if we take them seriously and put them in the system in the place to maximize performance, because otherwise why bother, the FPGAs you're calling for don't even live in all the same places. And when you get that one use case, you get specialized hardware, like GPUs. (Incidentally, GPUs are themselves another reason. Many of the things you might previously have cited as reasons to have FPGAs twenty years ago are now efficiently implemented in GPUs. No, not by any means all such problems, but enough that it carves another massive hunk of the use-case-space out of the FPGA-on-the-CPU argument.) Another way of looking at it is that the fundamental problem that FPGAs have is that it is physically impossible for them to beat dedicated hardware in the same configuration that you'd load into an FPGA, so once you have that popular use case, it gets put into normal silicon instead and outperforms the FPGAs.

by irq-1 9y ago

rjsw 9y ago

Interfacing FPGAs to PCI or PCIe isn't hard, there are plenty of dev boards available to let you add whatever you want. The ARM+FPGA chips work well too, the IO blocks are decoupled enough from the CPU that you can add your own offload engines.

jerf 9y ago

Then you fall off the other end of the scale: You don't have enough people clamoring for hardware acceleration of this whose needs aren't met by some already-existing plugin card or something. You aren't left with a niche of people who are making decisions about what CPU to buy based on what FPGAs they have, as a group, with sufficiently similar enough specs that they look like a single market to Intel or a chip maker. (That is, someone who just wants "a couple of instructions" and someone who wants "an FPGA for parsing HTTP2 requests" are dissimilar enough not to be the same thing.) In this case, being able to name a multiplicity of very edge use cases isn't an advantage; it is another reason why it doesn't happen. You need one big use that enough people agree on that it's economical to centralize it into the CPU, not a ton of scattered ones with radically different implications in terms of die size, how the data flows in and out, what percentage of users are using it, etc. In fact, in your use cases, if we take them seriously and put them in the system in the place to maximize performance, because otherwise why bother, the FPGAs you're calling for don't even live in all the same places. And when you get that one use case, you get specialized hardware, like GPUs. (Incidentally, GPUs are themselves another reason. Many of the things you might previously have cited as reasons to have FPGAs twenty years ago are now efficiently implemented in GPUs. No, not by any means all such problems, but enough that it carves another massive hunk of the use-case-space out of the FPGA-on-the-CPU argument.) Another way of looking at it is that the fundamental problem that FPGAs have is that it is physically impossible for them to beat dedicated hardware in the same configuration that you'd load into an FPGA, so once you have that popular use case, it gets put into normal silicon instead and outperforms the FPGAs.