From: Eugene Leitl (eugene.leitl@lrz.uni-muenchen.de)
Date: Fri Oct 06 2000 - 08:12:32 PDT
John Regehr writes:
> I would think that for the forseeable future compiling to hardware will
> be a semi-manual process where certain performance-critical, static
> algorithms are compiled to hardware and everything else is compiled to
> instructions. People who say otherwise* are full of it. It doesn't
FPGAs are good for high-speed (though slower than an ASIC)
low-complexity, potentially parallelizable algorithms. They're good
for RF DSP (since software is not fast enough), cryptography, digital
filters and multimedia, speeding up inner loops of scientific code,
and the like. Because you can't really fake connectivity of remote
pieces of hardware, they're potentially inefficient, and have their
limitations. Panacea FPGAs are not. But a step into the right
direction, very much yes.
> seem like a program such as Word or Linux could be sped up much by
> compiling to hardware, and I can't think of a good reason why somebody
> would take the time to try.
This indicates monolithic applications don't scale. For instance, with
current SHARC DSP technology you can build a ~50 k$/~1 TFlop/~1
GByte/~10^3 CPUs/~5 kW DSP workstation in a volume of a tower (even
without embedded RAM technology, it is anybody's guess how long it
takes until Moore's law makes the footprint, juice thirst and the
price shrink to more palatable regions). Whatever you do with it, you
have to fit it into asynchronous hardware message passing with ~1
MByte grains (compare parallel linear search of 1 GByte in 1 MByte
grains vs. 1 GByte in one piece). If your object doesn't fit into a
grain, you have to decompose it. You have to learn to live with
potentially 1000 truly concurrent program flows, even ignoring
conventional threading. Happy debugging.
Corollary: if we don't learn to develop for such hardware, we will be
forever stuck in the sequential tar pit (if you're not part of the
solution, you're part of the fossil record).
> > Trust: Would you trust Microsoft to rewire your computer? What
> > about the consequences of a virus?
>
> This isn't an issue as long as reconfigurable processors have a
> non-reconfigurable core. If a bug can't wedge your hardware into a
> nonrecoverable state, why would you care if you run Microsoft's
> algorithms in hardware or software?
Because FPGA is harder to trace and to reverse engineer. In principle,
you can imagine an FPGA which only accepts encrypted, digitally signed
code. If you're an unauthorized developer, tough luck.
(I don't trust Microsoft's algorithms whether in hardware or in
software, and hence don't run them. Ceterum censeo...).
This archive was generated by hypermail 2b29 : Fri Oct 06 2000 - 09:21:53 PDT