With Intel sending its "Larrabee" graphics co-processor out to pasture late last year - before it even reached the market - it is natural to assume that the chip maker is looking for something to boost the performance of high performance compute clusters and the supercomputer workloads they run. Nvidia has its Tesla co- …
What about Convey Computer?
I talked to them at SC09 and they had a pretty interesting product that might be a good fit for Intel.
Technical Strengths for HPC
Altera has a unique strength in the FPGA field, in that it has "antifuse" technology; links that can be programmed to open a circuit, rather than break one. This allows an FPGA to be more efficiently structured around smaller pieces.
The FPGAs from Lattice Semiconductor and Altera are programmed by means of on-chip flash memory.
Xilinx, however, has a different unique technolgy: on-chip RAM is used to contain the programming for the FPGA. This is such an obvious advantage when programs will be changed frequently that their technology would seem to be the only candidate for HPC applications. This doesn't rule out buying another FPGA company, and licensing crucial elements of the technology from Xilinx, of course.
Missing to obvious
FPGA's are a pig to program. Their great, they really are, and I'm sure they have a great future but I don't think the next release of gcc will offer much support for them.
You can already use gcc with FPGAs. Stick a processor on the FPGA and you can run the code on the FPGA itself. Otherwise, it is just a case of complying with an IO interface that your processor can use to talk to the FPGA and an agreed set of commands on an appropriate bus. What gcc doesn't directly allow you to do yet is recompile the hardware to update it to run algorithms you want. Although as software programmers are cheaper and easier to find this probably will happen sooner rather than later as there is a movement towards direct translation of software into hardware.
Ignorance may be bliss, but come on. I thought el reg readers weren't supposed to be complete muppets.
"a pig to program"
Programming any multicore or massively parallel application even in a proper programming language takes a certain amount of uncommon skill. Just ask anyone who was around twenty or so years ago when symmetric multiprocessing (and then vector processing) arrived in minicomputers.
gcc is slightly irrelevant to FPGAs (if we skip ghdl) but there are free (zero cost) tools which do work, and for big projects the savings are such that the commercial tools should be a worthwhile investment.
The question then becomes how do you program them, and who should program them?
Do you stick with the hardware-centric approaches such as VHDL, leaving the task to hardware designers who couldn't even spell algorithm let alone implement one efficiently?
Or do you switch to something like System-C (or alternatives), where the language looks familiar but a lack of familiarity with what's actually going on behind the scenes may lead to sub-optimal designs that are easy to read/write and impossible to debug?
Shall we stick with Fortran 90 and proper computers? I know it doesn't fill column inches, but it's tried tested proven and sometimes it even works...
agree with stan there. Most importantly the people who write HPC code don't know how to do it, and the people who have to support apps want no part of it - maybe when Fortran '27 is released....
Actel make antifuse or true flash based FPGA's.
Xilinx and Altera are SRAM based that must be configured using external flash etc. (Some have flash built in but same principle).
You can not use gcc to create an FPGA image, as you needs back end tools from the vendor for place and route.
"software programmers are cheaper and easier to find "
Windows wannabees might be cheap, but they're unreliable (they may not deliver, or what they deliver may not work). FPGAs aren't windows wannabee territory.
Real programmers/engineers, especially the kind that (a) know how to decompose algorithms in a manner where parallelisation might help (b) understand the ins and outs of the FPGA world, are as rare as rocking horse poo and need TLC (and dosh) accordingly.
Exhibit 1: the chap above who thinks putting a processor on an FPGA and running gcc output on it is in some way relevant. Complete muppet.