Marc: At this point, gcc 4.5.0 promises to be able to compile most Gambit-generated C files at high optimization levels in a "reasonable" amount of CPU time and memory. So I configured Gambit with ./configure CC='/pkgs/gcc-mainline/bin/gcc -march=core2 -msse4 -O3 -fschedule-insns' --enable-multiple-versions --enable-single-host" and then I removed by hand the "-O1" compilation options inserted into the makefiles by the configure script. The version of gcc I used was heine:~/programs/gambc-v4_5_2-devel> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --disable-multilib Thread model: posix gcc version 4.5.0 20091005 (experimental) [trunk revision 152459] (GCC) With my quickie benchmark program: gsi/gsi -e '(define a (time (expt 3 10000000)))(define b (time (* a a)))' the routine (direct-fft-recursive-4 a table) computed the final direct (forward) FFT with 2097152 complex elements in 156 ms. This means that we were getting
(/ (* 5 2097152 21) .156) 1411544615.3846154
FLOPS (because it takes $5 N \log_2 N$ floating-point operations for an FFT of size N). So that's 1411 MFLOPS with a 2.33 GHz Core 2 Duo; FFTW reports about 2200 MFLOPS on a 3.0 GHz Xeon Core Duo using the Intel compiler icc here: http://www.fftw.org/speed/CoreDuo-3.0GHz-icc64/ The Xeon has a faster memory bus and is generally faster than the Core 2 Duo clock-per-clock; but just the ratio of CPU speeds would give a rate of
(* 1411 (/ 3.0 2.33)) 1816.7381974248929
predicted MFLOPS for Gambit. I'm not going to get into a slanging match about gcc versus icc, but overall this looks pretty damn good. Brad
Afficher les réponses par date
On Oct 7, 2009, at 2:15 PM, Bradley Lucier wrote:
With my quickie benchmark program:
gsi/gsi -e '(define a (time (expt 3 10000000)))(define b (time (* a a)))'
the routine (direct-fft-recursive-4 a table) computed the final direct (forward) FFT with 2097152 complex elements in 156 ms. This means that we were getting
(/ (* 5 2097152 21) .156) 1411544615.3846154
FLOPS (because it takes $5 N \log_2 N$ floating-point operations for an FFT of size N). So that's 1411 MFLOPS with a 2.33 GHz Core 2 Duo; FFTW reports about 2200 MFLOPS on a 3.0 GHz Xeon Core Duo using the Intel compiler icc here:
http://www.fftw.org/speed/CoreDuo-3.0GHz-icc64/
The Xeon has a faster memory bus and is generally faster than the Core 2 Duo clock-per-clock; but just the ratio of CPU speeds would give a rate of
(* 1411 (/ 3.0 2.33)) 1816.7381974248929
predicted MFLOPS for Gambit.
Perhaps my understanding of current computer architectures is deficient :-P. I rebuilt Gambit on model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz with today's version of gcc and ./configure CC='/pkgs/gcc-mainline/bin/gcc -march=core2 -O3 -fschedule- insns' --enable-multiple-versions --enable-single-host --prefix=/pkgs/ Gambit-C and I got a time of 180 ms for the same FFT. So that's about 1222 MFLOPS. Since FFTW was running on a 3.0 GHz machine, that means an estimate of Gambit running at 1161 MFLOPS on the 3.0 GHz machine that the FFTW folks were using. So FFTW seems to still be about twice as fast as the Gambit code. I tried to build BenchFFT to compare FFTW and Gambit on the same machine, but one of the FFTs no longer compiles with a modern C++ compiler. Brad
Hallo, On Wed, Oct 7, 2009 at 6:15 PM, Bradley Lucier <lucier@math.purdue.edu> wrote:
the routine (direct-fft-recursive-4 a table) computed the final direct (forward) FFT with 2097152 complex elements in 156 ms. This means that we were getting
(/ (* 5 2097152 21) .156) 1411544615.3846154
FLOPS (because it takes $5 N \log_2 N$ floating-point operations for an FFT of size N). So that's 1411 MFLOPS with a 2.33 GHz Core 2 Duo; FFTW reports about 2200 MFLOPS on a 3.0 GHz Xeon Core Duo using the Intel compiler icc here:
1411 MFLOPS seems a lot but I am no expert. Does anybody can say how many MFLOPS a current 3D real-time game needs? Cheers, -- -alex http://www.ventonegro.org/
On Fri, Oct 09, 2009 at 03:33:35PM +0000, Alex Queiroz wrote:
1411 MFLOPS seems a lot but I am no expert. Does anybody can say how many MFLOPS a current 3D real-time game needs?
As many as you've got, essentially. I think that they mostly scale the game dynamically, to absorb what's available, either in terms of detail (how much is visible at once) and frame rate. The latest NVidia and ADI (AMD) graphics cards can do on the order of 1TFLOP (that's 1000 Gigaflops), which they use for physics modelling as well as polygon and texture rendering. Compare that to about 100 Gigaflops available on the latest Intel Nahelem cores[1]. The Cell processor in a Playstation3 gets about 150GFLOPs. One of the fastest floating point DSPs, the TMS320C672B-350 manages about 700MFLOP/s. Unfortunately, most of those flops aren't easily tapped for doing useful things like big FFTs or solving matrix equations... Not easy to get at from scheme, either, I would think (but would love to be shown that I'm wrong!) Cheers, -- Andrew [1] http://www.realworldtech.com/page.cfm?ArticleID=RWT090909050230
participants (3)
-
Alex Queiroz -
Andrew Reilly -
Bradley Lucier