FPGARelated.com
Forums

Scientific Computing on FPGA

Started by lanc...@gmail.com November 2, 2006
lancepickens@gmail.com wrote:
> Hi, > Coming from a scientific computing standpoint (with no hardware > experience). > I was wondering if you can improve any dedicated tasks by designing a > special > purpose chips ala FPGA to run your code? Does anyone have any > experience > with this?
National Instruments do plug-in FPGA cards for their LabView product. Dave
helmut.leonhardt@gmail.com wrote:

>Everything what can parallelize is possibly running faster in Hardware >than in Software.
Still, the amount of processing power a modern PC processor can deliver is enormous. It is problably more cost effective to optimize an algorithm to run parallel on 10 PC's than to develop a specific FPGA solution. If space is a constraint, the answer is in using blade servers. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nl
Nico Coesel wrote:
> helmut.leonhardt@gmail.com wrote: > > >Everything what can parallelize is possibly running faster in Hardware > >than in Software. > > Still, the amount of processing power a modern PC processor can > deliver is enormous. It is problably more cost effective to optimize > an algorithm to run parallel on 10 PC's than to develop a specific > FPGA solution. If space is a constraint, the answer is in using blade > servers. >
This is often true even for obvious applications of FPGA, PC can still be better. The analysis needs to account for factors such as floating point use, high locality referencing or lots of computing on tiny data sets and use of standard 32, 64 bit operands favors PCs On the other hand bit mangling, very high rates of memory shuffling, use of unusual bit wise or odd size mathematical operators and strategic use of buffer memories are a win for FPGAs. I suspect that as Flash drives replace hard drives at the 30GByte level the case for hardware taking control of data management in Flash only increases since a hardware FPGA design wouldn't usually include disk systems and can then push the PC host further away. Some problems can be factored both ways to get similar results in which case PCs still have the familiarity edge. Still a PC based solution that is just recompiled to hardware will perform far less well since it has already been factored to favor the PC. For a hardware solution, the software version can be viewed as the simulation of same hardware and most simulations usually run many orders slower than real hardware. This is why the best hardware solution is unlikeley to ever be achieved by software folks who have little experience in hardware who would force the FPGA to emulate the PC strengths. John Jakson transputer guy
The other area where FPGA's win is in latency.  Parallel or networked PC's 
cannot meet the latency requirements of many large computationally intensive 
real-time systems, even though they can meet the throughput requirements

Marco
________________________
Marc Reinig
UCO/Lick Observatory
Laboratory for Adaptive Optics


"JJ" <johnjakson@gmail.com> wrote in message 
news:1162578053.176232.266200@e3g2000cwe.googlegroups.com...
> > Nico Coesel wrote: >> helmut.leonhardt@gmail.com wrote: >> >> >Everything what can parallelize is possibly running faster in Hardware >> >than in Software. >> >> Still, the amount of processing power a modern PC processor can >> deliver is enormous. It is problably more cost effective to optimize >> an algorithm to run parallel on 10 PC's than to develop a specific >> FPGA solution. If space is a constraint, the answer is in using blade >> servers. >> > > This is often true even for obvious applications of FPGA, PC can still > be better. > > The analysis needs to account for factors such as floating point use, > high locality referencing or lots of computing on tiny data sets and > use of standard 32, 64 bit operands favors PCs On the other hand bit > mangling, very high rates of memory shuffling, use of unusual bit wise > or odd size mathematical operators and strategic use of buffer memories > are a win for FPGAs. > > I suspect that as Flash drives replace hard drives at the 30GByte level > the case for hardware taking control of data management in Flash only > increases since a hardware FPGA design wouldn't usually include disk > systems and can then push the PC host further away. > > Some problems can be factored both ways to get similar results in which > case PCs still have the familiarity edge. Still a PC based solution > that is just recompiled to hardware will perform far less well since > it has already been factored to favor the PC. > > For a hardware solution, the software version can be viewed as the > simulation of same hardware and most simulations usually run many > orders slower than real hardware. > > This is why the best hardware solution is unlikeley to ever be achieved > by software folks who have little experience in hardware who would > force the FPGA to emulate the PC strengths. > > John Jakson > transputer guy >
Thanks for the speedy reply everyone, I appreciate the help.

~Lance

On Nov 3, 10:26 am, "Marc Reinig" <M...@newsgroups.nospam> wrote:
> The other area where FPGA's win is in latency. Parallel or networked PC's > cannot meet the latency requirements of many large computationally intensive > real-time systems, even though they can meet the throughput requirements > > Marco > ________________________ > Marc Reinig > UCO/Lick Observatory > Laboratory for Adaptive Optics > > "JJ" <johnjak...@gmail.com> wrote in messagenews:1162578053.176232.266200@e3g2000cwe.googlegroups.com... > > > > > Nico Coesel wrote: > >> helmut.leonha...@gmail.com wrote: > > >> >Everything what can parallelize is possibly running faster in Hardware > >> >than in Software. > > >> Still, the amount of processing power a modern PC processor can > >> deliver is enormous. It is problably more cost effective to optimize > >> an algorithm to run parallel on 10 PC's than to develop a specific > >> FPGA solution. If space is a constraint, the answer is in using blade > >> servers. > > > This is often true even for obvious applications of FPGA, PC can still > > be better. > > > The analysis needs to account for factors such as floating point use, > > high locality referencing or lots of computing on tiny data sets and > > use of standard 32, 64 bit operands favors PCs On the other hand bit > > mangling, very high rates of memory shuffling, use of unusual bit wise > > or odd size mathematical operators and strategic use of buffer memories > > are a win for FPGAs. > > > I suspect that as Flash drives replace hard drives at the 30GByte level > > the case for hardware taking control of data management in Flash only > > increases since a hardware FPGA design wouldn't usually include disk > > systems and can then push the PC host further away. > > > Some problems can be factored both ways to get similar results in which > > case PCs still have the familiarity edge. Still a PC based solution > > that is just recompiled to hardware will perform far less well since > > it has already been factored to favor the PC. > > > For a hardware solution, the software version can be viewed as the > > simulation of same hardware and most simulations usually run many > > orders slower than real hardware. > > > This is why the best hardware solution is unlikeley to ever be achieved > > by software folks who have little experience in hardware who would > > force the FPGA to emulate the PC strengths. > > > John Jakson > > transputer guy
Marc Reinig wrote:
> The other area where FPGA's win is in latency. Parallel or networked PC's > cannot meet the latency requirements of many large computationally intensive > real-time systems, even though they can meet the throughput requirements > > Marco
Ofcourse, whipping up a quick list of platform benefits bound to miss some obvious ones. Also both platforms continually changing/improving but also getting harder to understand and less transparent. That alone makes it harder to compare since one mans optimized code is another mans starting point. Still the basic decider is likely to be whether one knows how to even start a FPGA. project.
> ________________________ > Marc Reinig > UCO/Lick Observatory > Laboratory for Adaptive Optics > > > "JJ" <johnjakson@gmail.com> wrote in message > news:1162578053.176232.266200@e3g2000cwe.googlegroups.com... > > > > Nico Coesel wrote: > >> helmut.leonhardt@gmail.com wrote: > >> > >> >Everything what can parallelize is possibly running faster in Hardware > >> >than in Software. > >> > >> Still, the amount of processing power a modern PC processor can > >> deliver is enormous. It is problably more cost effective to optimize > >> an algorithm to run parallel on 10 PC's than to develop a specific > >> FPGA solution. If space is a constraint, the answer is in using blade > >> servers. > >> > > > > This is often true even for obvious applications of FPGA, PC can still > > be better. > > > > The analysis needs to account for factors such as floating point use, > > high locality referencing or lots of computing on tiny data sets and > > use of standard 32, 64 bit operands favors PCs On the other hand bit > > mangling, very high rates of memory shuffling, use of unusual bit wise > > or odd size mathematical operators and strategic use of buffer memories > > are a win for FPGAs. > > > > I suspect that as Flash drives replace hard drives at the 30GByte level > > the case for hardware taking control of data management in Flash only > > increases since a hardware FPGA design wouldn't usually include disk > > systems and can then push the PC host further away. > > > > Some problems can be factored both ways to get similar results in which > > case PCs still have the familiarity edge. Still a PC based solution > > that is just recompiled to hardware will perform far less well since > > it has already been factored to favor the PC. > > > > For a hardware solution, the software version can be viewed as the > > simulation of same hardware and most simulations usually run many > > orders slower than real hardware. > > > > This is why the best hardware solution is unlikeley to ever be achieved > > by software folks who have little experience in hardware who would > > force the FPGA to emulate the PC strengths. > > > > John Jakson > > transputer guy > >
"JJ" <johnjakson@gmail.com> wrote:

> >Marc Reinig wrote: >> The other area where FPGA's win is in latency. Parallel or networked PC's >> cannot meet the latency requirements of many large computationally intensive >> real-time systems, even though they can meet the throughput requirements >> >> Marco > >Ofcourse, whipping up a quick list of platform benefits bound to miss >some obvious ones. > >Also both platforms continually changing/improving but also getting >harder to understand and less transparent. That alone makes it harder >to compare since one mans optimized code is another mans starting >point. > >Still the basic decider is likely to be whether one knows how to even >start a FPGA. project.
For any serious project this shouldn't be an issue. Last year I needed to warp video in real time to project video on an odd shape. It turned out a PC was more than fast enough for this task. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nl
"Ben Jones" <ben.jones@xilinx.com> wrote in message 
news:eif2gv$d6p1@cnn.xsj.xilinx.com...
> > FPGA scientific computing OMG ponies 15 >
:-) ...and you had the cheek to post that nonsense thread between me and Bob on your blog! Keep up the good work! Cheers mate, Syms.
JJ wrote
> > Still the basic decider is likely to be whether one knows how to even > start a FPGA. project.
Yes. Start by looking at scientific apps on GPUs: www.gpgpu.org
On Fri, 03 Nov 2006 16:36:12 +0000, Nico Coesel wrote:

> helmut.leonhardt@gmail.com wrote: > >>Everything what can parallelize is possibly running faster in Hardware >>than in Software.
On Fri, 03 Nov 2006 16:36:12 +0000, Nico Coesel wrote:
> Still, the amount of processing power a modern PC processor can deliver is > enormous. It is problably more cost effective to optimize an algorithm to > run parallel on 10 PC's than to develop a specific FPGA solution. If space > is a constraint, the answer is in using blade servers.
Plus, the FPGA can be clocked at say 200 MHz, 10 times less than the the CPU. Of course that doesn't mean that the CPU will be 10x faster, but the CPU's 'speed of light' is definitely much larger.