Re:Hardware is the new software
by jerf on Monday June 19, 2017 @01:29PM
(#14588676)
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.
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.