Austin Well I can't help with any FPU perf links just yet, I would have thought that QinetiQ would have a lot of that. I always thought sq root was in the same ballpark as division for cycles. The comp.arch NG often has sessions on FP math, some of the regulars are fairly clued up on it esp Nick M. As they say the only good benchmark is your own application and usually there's many other factors involved than raw SpecFP nos. Atleast FPGAs can be fairly "transparent" (if you can put a prototype synthesis together) where as figuring timing for OoO code can be tricky. JJ
Best FPGA for floating point performance
Started by ●August 19, 2005
Reply by ●August 19, 20052005-08-19
Reply by ●August 19, 20052005-08-19
"Austin Lesea" <austin@xilinx.com> wrote:> > Something I just couldn't find anywhere was the actual performance of > the x86 co-processor for something like a floating point square root.SQRT is generally done by software. Here are the number of clocks needed: http://www.intel.com/software/products/mkl/data/vml/functions/sqrt.html When you can compute several sqrt at once (vector) the use of the SIMD instructions (SSE) makes things better. On a 1000 single float vector an Itanium 2 takes only 5.14 cycles/sqrt> We have clock cycles for each IEEE floating point operator, and the > speed of the synthesized palced and routed core for various families, > from Spartan 3 to Virtex4 in that pdf file. > > I suppose uP software people don't really care about performance in > terms of cycles or ns or mops....its all about what game screen graphics > are displayed in the coolest fashion.... > > Does anyone have a link to such a site that has 'real' data of floating > point op performance?Look at the IA-32 Intel Architecture Optimization Reference Manual: ftp://download.intel.com/design/Pentium4/manuals/24896612.pdf In particular appendix C: IA-32 Instruction Latency and Throughput For instance the latency of a FPMUL is 7 clocks and you can put new operands every 2 clocks. (well 2 mult in // in SSE3) There is an FPSQRT which takes 40 clocks latency with a 40 clocks throughput. The MULT is much faster than a V4 but there can be more than one FPU in a V4 ;-) Marc
Reply by ●August 19, 20052005-08-19
Here we go again. Either one will do quite well with floating point, but the performance is entirely dependent on the implementation. There is nothing significant that is native to either one that makes one better than the other for floating point. That said, the 18 x 18 embedded multipliers in both families are a PITA for IEEE floats. It would be much easier with 24x24 multipliers. Once again, I could easily code an RTL design that is "portable" so that it favors either family, especially when the DSP elements are involved. Austin Lesea wrote:> Marc, > > IEEE floating point standard? You need to be more specific. > > Does it need to integrate with a processor? > > I believe the Xilinx IBM 405 Power PC using the APU interface in > Virtex 4 with the floating point IP core provides the best and fastest > performance. > > Especially since no other FPGA vendor has a hardened processor to > compete with us. > > If all you want is the floating point processing, without a > microprocessor, then I think you will find similar performance between > Xilinx and our competition, with us (of course) claiming the superior > performance edge. > > It would not surprise me at all to see them also post claiming they > are superior. > > For a specific floating point core, with a given precision, for given > features, it would be pretty easy to bench mark, so there is very > little wiggle room here for marketing nonsense. > > I would be interested to hear from others (not competitors) about what > floating point cores they use, and how well they perform (as you > obviously are interested). > > Austin > > > Marc Battyani wrote: > >> Hello, >> >> Does anybody already made a comparison of the high performance FPGA >> (Stratix >> II, V4, ?) relative to double precision floating point performance (add, >> mult, div, etc.) ? >> >> It's for an HPC aplication. >> >> Thanks >> >> Marc >> >>-- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
Reply by ●August 19, 20052005-08-19
In article <11gcl358r608m9e@corp.supernews.com>, Marc Battyani <Marc.Battyani@fractalconcept.com> wrote:>I find it somewhat depressing to see that Cray can't come up with something >much better than a bunch of FPGAs but at the same time it's very cool to >have access to the same technology than Cray. Or even better as they seem to >use Virtex II :)Remember that Cray are not in an absolute sense a very large company; market cap about a hundred million, sales fifty million in a good quarter, and very little of that profit. Xilinx could buy them with six weeks of their profit. The Cray XD1 with the FPGAs in it is basically a product of Octiga Bay, a smallish Canadian start-up that Cray bought outright eighteen months back when Cray's shares were worth rather more; there's one impressive ASIC in there, and that's the big system router. I admit to daydreams of a fractal-generating board about the size of a postcard tiled with XC3S1500 chips; six 17x17 multipliers make a 3:48 x 3:48 by a Karatsuba-like process, which is enough for reasonably deep zooming into most complex-plane fractals. Four of those fit in one $75 chip with multipliers left over to assist the divider, six of those chips on a board ... but I never got the state machines to drive them working correctly in Modelsim, let alone on a physical chip, let alone on a card-full, and I wouldn't know where to start with the PCB layout. [also, I doubt there's a market for $500 Newton-set generators, except possibly as a *shiny*maths* exhibit in museums, of which there are not all _that_ many] Tom
Reply by ●August 19, 20052005-08-19
In article <WjtNe.1215$L03.637@newssvr27.news.prodigy.net>, Austin Lesea <austin@xilinx.com> wrote:>JJ, > >Something I just couldn't find anywhere was the actual performance of >the x86 co-processor for something like a floating point square root.Intel's manuals are on-line at http://intel.com/design/pentium4/manuals/index_new.htm In a locked filing cabinet concealed in a disused lavatory you will find Document 248966, which has, in appendix C, guarded by a leopard, performance figures. For the vector unit, you have PD and PS versions; PD instructions do two independent double-precision operations, PS instructions do four independent single-precision ones. PD PS + 2/4 2/6 * 2/6 2/6 / 70 40 Sqrt 70 40 '2/4' and '2/6' mean that the machine can accept a new pair of operands every two ticks, but only produces the answer six ticks later; it's quite deeply pipelined. The multiply and add pipelines run simultaneously. So a 3.6GHz Pentium 4, which costs about $600 (comparable to a V4LX40, I suppose, though the Pentium's in a vastly more convenient package) can do about a hundred million double-precision square roots per second, and about fourteen billion single-precision floating-point operations. The figures in http://www.xilinx.com/bvdocs/ipcenter/data_sheet/floating_point.pdf suggest that the V4 isn't entirely competitive even in tasks parallel enough for the MFlops figure to be maximum frequency * slices-in-chip / slices-in-core. Not altogether surprising given that Intel devotes most of its R&D efforts to making Pentium 4s faster, and has an annual R&D budget equal to 250% of Xilinx's total revenue. If you replaced a few of those DSP48 units with full-custom FPUs, on another hand ...> Does anyone have a link to such a site that has 'real' data of > floating point op performance?Does this help? They're very much guaranteed-not-to-exceed figures (I have achieved them, but not in loops doing useful work), but only comparably fanciful to f_max values. Tom
Reply by ●August 20, 20052005-08-20
Tom, Wow. Talk about buried. But thanks. Looks like for double precision the Qinetic core is on par (per my earlier post). If we replaced the DSP48 with a mor powerful block, then we woul dof course have that covered. Just stay tuned. The DSP48 is evolving as we hear back from customers how to make it work even better (ie more features). Austin
Reply by ●August 25, 20052005-08-25
Marc Battyani wrote:> Does anybody already made a comparison of the high performance FPGA (Stratix > II, V4, ?) relative to double precision floating point performance (add, > mult, div, etc.) ?As far as I know, the biggest problem with floating point in FPGAs is the barrel shifter needed to pre and post normalize addition (and subtraction). Floating point multiply and divide are a little harder than fixed point, but the post normalization only needs to shift one bit. (I think that is right, but maybe two.) I would assume you can set the rounding mode at compile time, and any other applicable IEEE mode bits. -- glen
Reply by ●August 25, 20052005-08-25
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote> Marc Battyani wrote: > > > Does anybody already made a comparison of the high performance FPGA(Stratix> > II, V4, ?) relative to double precision floating point performance (add, > > mult, div, etc.) ? > > As far as I know, the biggest problem with floating point > in FPGAs is the barrel shifter needed to pre and post normalize > addition (and subtraction). > > Floating point multiply and divide are a little harder than fixed > point, but the post normalization only needs to shift one bit. > (I think that is right, but maybe two.) > > I would assume you can set the rounding mode at compile time, and > any other applicable IEEE mode bits.In fact I'm not sure that full IEEE floating point accuracy is needed. For sure single precision is not enough but probably double precision is not really needed. The problem is that people who write the algorithms do it in C(++) using double precision floats and they use double precision libraries, etc. So it's not obvious to see what precision is really needed. After all in an FPGA we can use the exact number of bit needed. (In fact it is even possible that a fixed point format could work) Marc
Reply by ●August 26, 20052005-08-26
Regarding x86 vs FPGA for double-precision floating-point arithmetic: Good points about the relative performances, but you need to look at more than the peak FLOPs/s to do a comparison between the architectures. Non-trivial double precision algorithms running on microprocessors can use anything between 5 and 90 % of their peak FLOPs/s. Floating-point algorithms are typically memory bound for microprocessors. FPGAs on the other hand are typically bound by peak FLOPs/s. FPGAs are able to significantly outperform modern microprocessors on memory bandwidth sensitive double precision operations. Microprocessors still beat FPGAs for non-memory bound operations because they have higher peak FLOPs/s, but this situation won't last. Peak FLOPs/s for FPGAs are set to exceed those of uP's in the not too distant future. To chase the increases in peak FLOPs/s on microprocessors you need ever more complex memory hierarchies, while in FPGAs it looks like it will be some time before such techniques will be needed to get the most out of the floating-point units.
Reply by ●August 26, 20052005-08-26
