For a parallel algorithm are FPGAs the way to go or multi-processors? Let's assume fixed-point arithmetic to keep an even playing field.
Multiple Processors versus FPGAs
Started by ●May 20, 2014
Reply by ●May 20, 20142014-05-20
On 5/20/2014 3:22 PM, gyansorova@gmail.com wrote:> For a parallel algorithm are FPGAs the way to go or multi-processors? > Let's assume fixed-point arithmetic to keep an even playing field.There is still a lot of issues which will determine which way you will want to go. Can you give more details about your algorithms? For example, what is your data rate? Not only does an FPGA provide a lot of potential processing power, they provide virtually unlimited comms bandwidth internally. Any logic block can communicate with another logic block as fast as they can compute. You can't say that about an N-way processing array implemented with DSP chips where comms speed can be a major bottleneck. DSPs, however, provide a programming environment that is more familiar to most developers. That is a big issue in many organizations. Personally I find FPGAs to be easier to design with as they remove many restrictions and I am accustomed to the FPGA design process. Most DSP developers think in terms of coarse grained parallelism while FPGAs are capable of very fine grained parallelism. You will find a lot of bias against FPGAs with people claiming "it costs a fortune" to develop the same code on an FPGA. It is amazing how FPGA designs can ever be completed. Mostly this is simply a lack of familiarity with FPGAs. -- Rick
Reply by ●May 20, 20142014-05-20
On Tue, 20 May 2014 12:22:22 -0700, gyansorova wrote:> For a parallel algorithm are FPGAs the way to go or multi-processors?Yes.> Let's assume fixed-point arithmetic to keep an even playing field.That narrows my answer down to "yes". Or maybe "it depends on the algorithm and possibly the business environment of the product". -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●May 20, 20142014-05-20
On Wednesday, May 21, 2014 8:32:47 AM UTC+12, rickman wrote:> On 5/20/2014 3:22 PM, gyansorova@gmail.com wrote: > > > For a parallel algorithm are FPGAs the way to go or multi-processors? > > > Let's assume fixed-point arithmetic to keep an even playing field. > > > > There is still a lot of issues which will determine which way you will > > want to go. Can you give more details about your algorithms? For > > example, what is your data rate? Not only does an FPGA provide a lot of > > potential processing power, they provide virtually unlimited comms > > bandwidth internally. Any logic block can communicate with another > > logic block as fast as they can compute. You can't say that about an > > N-way processing array implemented with DSP chips where comms speed can > > be a major bottleneck. > > > > DSPs, however, provide a programming environment that is more familiar > > to most developers. That is a big issue in many organizations. > > Personally I find FPGAs to be easier to design with as they remove many > > restrictions and I am accustomed to the FPGA design process. > > > > Most DSP developers think in terms of coarse grained parallelism while > > FPGAs are capable of very fine grained parallelism. > > > > You will find a lot of bias against FPGAs with people claiming "it costs > > a fortune" to develop the same code on an FPGA. It is amazing how FPGA > > designs can ever be completed. Mostly this is simply a lack of > > familiarity with FPGAs. > > > > -- > > > > RickI suppose even if you get fast coms between CPUs you then need a parallel compiler to best make use of hardware. Unless you manually specify which processor the code is to be run on.
Reply by ●May 20, 20142014-05-20
On 5/20/2014 5:15 PM, gyansorova@gmail.com wrote:> On Wednesday, May 21, 2014 8:32:47 AM UTC+12, rickman wrote: >> >> You will find a lot of bias against FPGAs with people claiming "it costs >> >> a fortune" to develop the same code on an FPGA. It is amazing how FPGA >> >> designs can ever be completed. Mostly this is simply a lack of >> >> familiarity with FPGAs. > > I suppose even if you get fast coms between CPUs you then need a parallel compiler to best make use of hardware. Unless you manually specify which processor the code is to be run on.I have never understood the need to have tasks automatically partitioned and assigned to processors. Designing FPGAs is basically that, but in essence done manually. That is what you are doing when coding in an HDL, defining the processes and of course, in hardware each process has it's own processor. If you are using multiple processors, why can't you just decide what is run where and when? -- Rick
Reply by ●May 20, 20142014-05-20
gyansorova@gmail.com wrote:> For a parallel algorithm are FPGAs the way to go or multi-processors? > Let's assume fixed-point arithmetic to keep an even playing field.If a single DSP can do it, that is probably the way to go. If the algorithm itself is simple, but you need to do (whatever it does) a really huge number of times, and especially in fixed point, then FPGA is likely the way to go. Specifically, look into systolic array processors. It is fairly easy to write a systolic array for an FPGA, at which point you still need some way, such as a microprocessor, to get data into, and out of, the array. If the algorithm doesn't map onto a systolic array, that is, it isn't a large number of relatively simple operations, then a parallel multiprocessor, using something like MPI to keep track of the data, might be the way to go. -- glen
Reply by ●May 20, 20142014-05-20
On Wednesday, May 21, 2014 9:19:17 AM UTC+12, rickman wrote:> On 5/20/2014 5:15 PM, gyansorova@gmail.com wrote: > > > On Wednesday, May 21, 2014 8:32:47 AM UTC+12, rickman wrote: > > >> > > >> You will find a lot of bias against FPGAs with people claiming "it costs > > >> > > >> a fortune" to develop the same code on an FPGA. It is amazing how FPGA > > >> > > >> designs can ever be completed. Mostly this is simply a lack of > > >> > > >> familiarity with FPGAs. > > > > > > I suppose even if you get fast coms between CPUs you then need a parallel compiler to best make use of hardware. Unless you manually specify which processor the code is to be run on. > > > > I have never understood the need to have tasks automatically partitioned > > and assigned to processors. Designing FPGAs is basically that, but in > > essence done manually. That is what you are doing when coding in an > > HDL, defining the processes and of course, in hardware each process has > > it's own processor. > > > > If you are using multiple processors, why can't you just decide what is > > run where and when? > > > > -- > > > > RickIt depends on what you are doing. Many Physics and computer science people run algorithms on multiple GPUs and use tools like parallel C and parallel Fortran. It's not all DSP stuff, it could be solving partial differential equations for instance in a supercomputer.
Reply by ●May 20, 20142014-05-20
On 5/20/2014 9:36 PM, gyansorova@gmail.com wrote:> On Wednesday, May 21, 2014 9:19:17 AM UTC+12, rickman wrote: >> >> If you are using multiple processors, why can't you just decide what is >> >> run where and when? >> > It depends on what you are doing. Many Physics and computer science people run algorithms on multiple GPUs and use tools like parallel C and parallel Fortran. > It's not all DSP stuff, it could be solving partial differential equations for instance in a supercomputer.So what is your point? I'm not following exactly. Someone said that you *need* a parallel compiler to code for multiple DSPs. You can use them if you wish, but why are they *necessary*? -- Rick
Reply by ●May 21, 20142014-05-21
>It depends on what you are doing. Many Physics and computer science people run >algorithms on multiple GPUs and use tools like parallel C and parallel Fortran. >It's not all DSP stuff, it could be solving partial differential equations for >instance in a supercomputer.I'll add that GPUs are emerging as a formidable alternative to FPGAs and DSPs. For parallel algorithms, their performance can be orders of magnitude higher than DSPs, rivaling that of an FPGA. Accessibility is an added benefit since most modern computers already include a GPU.
Reply by ●May 21, 20142014-05-21
On Tue, 20 May 2014 14:15:31 -0700, gyansorova wrote:> On Wednesday, May 21, 2014 8:32:47 AM UTC+12, rickman wrote: >> On 5/20/2014 3:22 PM, gyansorova@gmail.com wrote: >> >> > For a parallel algorithm are FPGAs the way to go or multi-processors? >> >> > Let's assume fixed-point arithmetic to keep an even playing field. >> >> >> >> There is still a lot of issues which will determine which way you will >> >> want to go. Can you give more details about your algorithms? For >> >> example, what is your data rate? Not only does an FPGA provide a lot >> of >> >> potential processing power, they provide virtually unlimited comms >> >> bandwidth internally. Any logic block can communicate with another >> >> logic block as fast as they can compute. You can't say that about an >> >> N-way processing array implemented with DSP chips where comms speed can >> >> be a major bottleneck. >> >> >> >> DSPs, however, provide a programming environment that is more familiar >> >> to most developers. That is a big issue in many organizations. >> >> Personally I find FPGAs to be easier to design with as they remove many >> >> restrictions and I am accustomed to the FPGA design process. >> >> >> >> Most DSP developers think in terms of coarse grained parallelism while >> >> FPGAs are capable of very fine grained parallelism. >> >> >> >> You will find a lot of bias against FPGAs with people claiming "it >> costs >> >> a fortune" to develop the same code on an FPGA. It is amazing how FPGA >> >> designs can ever be completed. Mostly this is simply a lack of >> >> familiarity with FPGAs. >> >> >> >> -- >> >> >> >> Rick > > I suppose even if you get fast coms between CPUs you then need a > parallel compiler to best make use of hardware. Unless you manually > specify which processor the code is to be run on.There's a growing body of knowledge on this, because processor makers like Intel are delivering faster processors with "multi-core", which is essentially more than one processor in a package, all talking to the same cache. If you're talking about FPGA's, you misunderstand what they are. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
