8 ms·

This is great! I think that some time in the future, FPGA will be a vital part for data processing. In theory, an application with a computation-heavy task cou

by sddfd 8y ago

This is great! I think that some time in the future, FPGA will be a vital part for data processing. In theory, an application with a computation-heavy task could program the FPGA to provide part of that task in hardware (think the hot innermost loop body). What I am worried about is the infrastructure that is needed to make this happen: Is there even support for this in our compilers? What would support look like?

chrisseaton 8y ago
> Is there even support for this in our compilers? What would support look like? FPGA offload has been a very active area of compiler research for more than a decade. I like this paper for example https://dri.es/files/fpl05-paper.pdf https://dri.es/files/fpl05-paper.pdf
baybal2 8y ago
There is software that can poorly map OpenCL calls onto HDL code. It is still light years behind a human designer.
qubex 8y ago
Back in the mid-to-late nineties, Federico Faggin, designer of Intel's seminal 4004 (and ancestor of the whole x86 lineage) co-founded a company called Starbridge Systems that aimed to construct and sell what they termed hypercomputers whose architecture was rapidly-reconfiguring FPGAs that an enabled a compile-to-hardware model. Here's one of the few references to that project that I can now find online, a WIRED era piece with all the gushing nerd optimism of the pre-dot-com-bust: https://www.wired.com/1999/02/the-super-duper-hypercomputer/ https://www.wired.com/1999/02/the-super-duper-hypercomputer/ I suppose this is where Intel is headed now with these first few tentative steps.
- zantana 8y ago
  Isn't this what Transmeta was also trying to do? https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/Transmeta
pjc50 8y ago
> In theory, an application with a computation-heavy task could program the FPGA to provide part of that task in hardware (think the hot innermost loop body). This is absurdly far away; it reminds me of the decades of assumption that 4GLs are going to obsolete programmers or the decades of trying to cross-compile C to FPGAs, badly. It doesn't help that there's a huge infrastructure barrier caused by closed tools. Imagine if Intel brought out a processor with a proprietary instruction set where you were only allowed to use their FORTRAN compiler (no C, let alone anything more modern or JIT) with a per-seat license. That's where FPGA tools are. We won't see a Cambrian explosion in FPGA tooling until they are made properly open. Building using open-source tools needs to be actively supported by the manufacturer. There are also conceptual obstacles; FPGAs are sufficiently different that programmers have to re-learn and re-write idioms in order to get usable results. It's as big a jump as going from Javascript to CUDA.
- pasabagi 8y ago
  With the end of Moore's law, won't this kind of thing become increasingly necessary, though? I agree with you about the problems of closed-source - but I feel like the end of Moore's law will encourage creative solutions to performance problems - which FPGAs would at least make technically possible. And, even if it's like the old days when people bought compilers and access to source, people will still do it - since it'll be the best way to get an edge on the competition.
amelius 8y ago
> think the hot innermost loop body In many applications data access is the bottleneck, and an FPGA coprocessor will not give any improvements in that area. Using an FPGA to do arithmetic computations (e.g. as in audio/video coding) could provide a benefit, but I fail to see how this improves things much over having an extra CPU core. The only thing an FPGA does is replace registers by wires, basically, and there's not much to be gained there, I guess.
- stmw 8y ago
  I am not sure that's necessarily true as long as the FPGA has access to the CPU bus - as it seems to here - as opposed to hanging off a slower peripheral bus - as a lot of other FPGA experiments/cards have done in the past. If you don't penalize the FPGA with slower data access, it can make a big difference for many (albeit not all) applications.
jpfed 8y ago
It is possible to imagine a future in which no one outside the processor manufacturer needs to do a damn thing. Nowadays, no one else knows or cares what microcode is used to execute x86 instructions. Maybe someday hot enough sections of code will get transparently JITted to logic gates.

by sddfd 8y ago

chrisseaton 8y ago

> Is there even support for this in our compilers? What would support look like? FPGA offload has been a very active area of compiler research for more than a decade. I like this paper for example https://dri.es/files/fpl05-paper.pdf https://dri.es/files/fpl05-paper.pdf

baybal2 8y ago

There is software that can poorly map OpenCL calls onto HDL code. It is still light years behind a human designer.

qubex 8y ago

Back in the mid-to-late nineties, Federico Faggin, designer of Intel's seminal 4004 (and ancestor of the whole x86 lineage) co-founded a company called Starbridge Systems that aimed to construct and sell what they termed hypercomputers whose architecture was rapidly-reconfiguring FPGAs that an enabled a compile-to-hardware model. Here's one of the few references to that project that I can now find online, a WIRED era piece with all the gushing nerd optimism of the pre-dot-com-bust: https://www.wired.com/1999/02/the-super-duper-hypercomputer/ https://www.wired.com/1999/02/the-super-duper-hypercomputer/ I suppose this is where Intel is headed now with these first few tentative steps.

zantana 8y ago
Isn't this what Transmeta was also trying to do? https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/Transmeta

pjc50 8y ago

> In theory, an application with a computation-heavy task could program the FPGA to provide part of that task in hardware (think the hot innermost loop body). This is absurdly far away; it reminds me of the decades of assumption that 4GLs are going to obsolete programmers or the decades of trying to cross-compile C to FPGAs, badly. It doesn't help that there's a huge infrastructure barrier caused by closed tools. Imagine if Intel brought out a processor with a proprietary instruction set where you were only allowed to use their FORTRAN compiler (no C, let alone anything more modern or JIT) with a per-seat license. That's where FPGA tools are. We won't see a Cambrian explosion in FPGA tooling until they are made properly open. Building using open-source tools needs to be actively supported by the manufacturer. There are also conceptual obstacles; FPGAs are sufficiently different that programmers have to re-learn and re-write idioms in order to get usable results. It's as big a jump as going from Javascript to CUDA.

pasabagi 8y ago
With the end of Moore's law, won't this kind of thing become increasingly necessary, though? I agree with you about the problems of closed-source - but I feel like the end of Moore's law will encourage creative solutions to performance problems - which FPGAs would at least make technically possible. And, even if it's like the old days when people bought compilers and access to source, people will still do it - since it'll be the best way to get an edge on the competition.

amelius 8y ago

> think the hot innermost loop body In many applications data access is the bottleneck, and an FPGA coprocessor will not give any improvements in that area. Using an FPGA to do arithmetic computations (e.g. as in audio/video coding) could provide a benefit, but I fail to see how this improves things much over having an extra CPU core. The only thing an FPGA does is replace registers by wires, basically, and there's not much to be gained there, I guess.

stmw 8y ago
I am not sure that's necessarily true as long as the FPGA has access to the CPU bus - as it seems to here - as opposed to hanging off a slower peripheral bus - as a lot of other FPGA experiments/cards have done in the past. If you don't penalize the FPGA with slower data access, it can make a big difference for many (albeit not all) applications.

jpfed 8y ago

It is possible to imagine a future in which no one outside the processor manufacturer needs to do a damn thing. Nowadays, no one else knows or cares what microcode is used to execute x86 instructions. Maybe someday hot enough sections of code will get transparently JITted to logic gates.