26 Feb
2004
26 Feb
'04
12:13 p.m.
Hello,
DRC 2.4.0 has been released and it is available at:
http://freshmeat.net/projects/drc/
Changes in this release:
The Takuya Ooura and GNU Scientific Library FFT routines have been included
in the program. These routines are about 10 times faster than the previous
routines, providing about the same accuracy.
Best of listening,
--
Denis Sbragion
InfoTecna
Tel: +39 0362 805396, Fax: +39 0362 805404
URL: http://www.infotecna.it
26 Feb
26 Feb
2:11 p.m.
On Thu, Feb 26, 2004 at 06:01:28PM +0100, Denis Sbragion wrote:
The Takuya Ooura and GNU Scientific Library FFT
routines have been included
in the program. These routines are about 10 times faster than the previous
routines, providing about the same accuracy.
What was the previous library, out of interest?
- Steve
27 Feb
27 Feb
2:59 a.m.
Hello Steve,
At 19.06 26/02/2004 +0000, you wrote:
What was the previous library, out of interest?
developed by me more than 10 years ago when I was still at school. Nothing
exceptional, just a programming exercise that turned out to be useful when
I started writing DRC.
Bye,
--
Denis Sbragion
InfoTecna
Tel: +39 0362 805396, Fax: +39 0362 805404
URL: http://www.infotecna.it
4:27 a.m.
On Fri, Feb 27, 2004 at 08:47:21 +0100, Denis Sbragion wrote:
Hello Steve,
At 19.06 26/02/2004 +0000, you wrote:
Ah. OK. How do the other libraries you're using benchmark against FFTW3?
- Steve
What was the previous library, out of interest?
developed by me more than 10 years ago when I was still at school. Nothing
exceptional, just a programming exercise that turned out to be useful when
I started writing DRC.
6:22 a.m.
Hello Steve,
At 09.22 27/02/2004 +0000, you wrote:
Ah. OK. How do the other libraries you're using
benchmark against FFTW3?
don't understand if you're referring to my FFT routines or the others. My
FFT routines are about 10 times slower than GSL FFT, which are about 3 to 4
times slower than FFTW3, so probaly they are 30 to 40 times slower than
FFTW3. My FFT routines are far from interesting, apart from being written
in c++ using the native STL complex dataype and being compact and easy to use.
The GSL mixed radix FFT is reported to be 3 to 4 times slower than
FFTW3 in the FFTW3 web sites, the Ooura ones are instead reported as 30-40%
slower than FFTW3 (they're only radix 2 though), but in my tests they seems
to be no more than 20-30% faster than GSL mixed radix, so they should be
much slower than FFTW3. The Ooura website report them as being a little
faster than FFTW2 (see http://momonga.t.u-tokyo.ac.jp/~ooura/fftbmk.html).
Don't know if it is the way I use them (I perform really long FFTs
of complex data, the FFTW3 benchmark instead stops at around 260.000
items), or just the FFTW3 benchmark that is using different versions, but
my data don't correlate really well with the FFTW3 benchmarks. Anyway take
all this data with a grain of salt, these are just my impressions, not
accurately measured benchmarks, which by itself should be taken already
with more than a grain of salt.
Bye,
--
Denis Sbragion
InfoTecna
Tel: +39 0362 805396, Fax: +39 0362 805404
URL: http://www.infotecna.it
2:09 p.m.
On Fri, 2004-02-27 at 13:10, Denis Sbragion wrote:
Don't know if it is the way I use them (I
perform really long FFTs
of complex data, the FFTW3 benchmark instead stops at around 260.000
items), or just the FFTW3 benchmark that is using different versions, but
my data don't correlate really well with the FFTW3 benchmarks. Anyway take
all this data with a grain of salt, these are just my impressions, not
accurately measured benchmarks, which by itself should be taken already
with more than a grain of salt.
Here are some numbers from my benchmark... On 2.4 GHz Celeron.
Ooura:
59 us / 1024 point complex FFT (single), 16949 FFTs/s, 17.356 MS/s
86 us / 1024 point complex FFT (double), 11628 FFTs/s, 11.907 MS/s
32 us / 1024 point real FFT (single), 31250 FFTs/s, 32.000 MS/s
365 us / 8192 point real FFT (single), 2740 FFTs/s, 22.444 MS/s
8350 us / 65536 point real FFT (single), 120 FFTs/s, 7.849 MS/s
FFTW3:
43 us / 1024 point complex FFT (single), 23256 FFTs/s, 23.814 MS/s
70 us / 1024 point complex FFT (double), 14286 FFTs/s, 14.629 MS/s
42 us / 1024 point real FFT (single), 23810 FFTs/s, 24.381 MS/s
490 us / 8192 point real FFT (single), 2041 FFTs/s, 16.718 MS/s
30420 us / 65536 point real FFT (single), 33 FFTs/s, 2.154 MS/s
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
28 Feb
28 Feb
8:53 a.m.
[Jussi Laako]
Here are some numbers from my benchmark... On 2.4 GHz
Celeron.
Ooura:
59 us / 1024 point complex FFT (single), 16949 FFTs/s, 17.356 MS/s
86 us / 1024 point complex FFT (double), 11628 FFTs/s, 11.907 MS/s
32 us / 1024 point real FFT (single), 31250 FFTs/s, 32.000 MS/s
365 us / 8192 point real FFT (single), 2740 FFTs/s, 22.444 MS/s
8350 us / 65536 point real FFT (single), 120 FFTs/s, 7.849 MS/s
FFTW3:
43 us / 1024 point complex FFT (single), 23256 FFTs/s, 23.814 MS/s
70 us / 1024 point complex FFT (double), 14286 FFTs/s, 14.629 MS/s
42 us / 1024 point real FFT (single), 23810 FFTs/s, 24.381 MS/s
490 us / 8192 point real FFT (single), 2041 FFTs/s, 16.718 MS/s
30420 us / 65536 point real FFT (single), 33 FFTs/s, 2.154 MS/s
seems Ooura is quicker than FFTW3 for real DFT, surprises me.
is the benchmark code you use available somewhere?
cheers,
tim
9:58 a.m.
On Sat, Feb 28, 2004 at 02:43:18PM +0100, Tim Goetze wrote:
[Jussi Laako]
Do you have the SIMD optimisations on, and have you tried the
"halfcomplex" mode of FFTW, thats fine for audio, and saves some memory
i/o.
- Steve
Here are some numbers from my benchmark... On 2.4
GHz Celeron.
Ooura:
59 us / 1024 point complex FFT (single), 16949 FFTs/s, 17.356 MS/s
86 us / 1024 point complex FFT (double), 11628 FFTs/s, 11.907 MS/s
32 us / 1024 point real FFT (single), 31250 FFTs/s, 32.000 MS/s
365 us / 8192 point real FFT (single), 2740 FFTs/s, 22.444 MS/s
8350 us / 65536 point real FFT (single), 120 FFTs/s, 7.849 MS/s
FFTW3:
43 us / 1024 point complex FFT (single), 23256 FFTs/s, 23.814 MS/s
70 us / 1024 point complex FFT (double), 14286 FFTs/s, 14.629 MS/s
42 us / 1024 point real FFT (single), 23810 FFTs/s, 24.381 MS/s
490 us / 8192 point real FFT (single), 2041 FFTs/s, 16.718 MS/s
30420 us / 65536 point real FFT (single), 33 FFTs/s, 2.154 MS/s
seems Ooura is quicker than FFTW3 for real DFT, surprises me.
10:58 a.m.
New subject: Ooura vs FFTW3, Re: [linux-audio-dev] DRC 2.4.0
[Steve Harris]
On Sat, Feb 28, 2004 at 02:43:18PM +0100, Tim Goetze
wrote:
i assume 'halfcomplex' is what is called 'real' in Jussi's benchmark
output. one thing that makes me wonder is that my copy of Ooura's
routines seems to work with double precision only.
btw, http://www.fftw.org/speed/ paints an altogether different
picture.
tim
[Jussi Laako]
Do you have the SIMD optimisations on, and have you tried the
"halfcomplex" mode of FFTW, thats fine for audio, and saves some memory
i/o. Here are some numbers from my benchmark... On 2.4
GHz Celeron.
Ooura:
59 us / 1024 point complex FFT (single), 16949 FFTs/s, 17.356 MS/s
86 us / 1024 point complex FFT (double), 11628 FFTs/s, 11.907 MS/s
32 us / 1024 point real FFT (single), 31250 FFTs/s, 32.000 MS/s
365 us / 8192 point real FFT (single), 2740 FFTs/s, 22.444 MS/s
8350 us / 65536 point real FFT (single), 120 FFTs/s, 7.849 MS/s
FFTW3:
43 us / 1024 point complex FFT (single), 23256 FFTs/s, 23.814 MS/s
70 us / 1024 point complex FFT (double), 14286 FFTs/s, 14.629 MS/s
42 us / 1024 point real FFT (single), 23810 FFTs/s, 24.381 MS/s
490 us / 8192 point real FFT (single), 2041 FFTs/s, 16.718 MS/s
30420 us / 65536 point real FFT (single), 33 FFTs/s, 2.154 MS/s
seems Ooura is quicker than FFTW3 for real DFT, surprises me.
5:08 p.m.
New subject: Ooura vs FFTW3, Re: [linux-audio-dev] DRC 2.4.0
On Sat, 2004-02-28 at 17:47, Tim Goetze wrote:
i assume 'halfcomplex' is what is called
'real' in Jussi's benchmark
output. one thing that makes me wonder is that my copy of Ooura's
routines seems to work with double precision only.
libDSP contains (among other things) C++ class implementation of
float&double version of Ooura radix-4, radix-8 and split-radix
transforms.
Using Ooura (built-in), FFTW (external) and Intel IPP (external) FFTs
with libDSP is just matter of configuration #define.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
5:13 p.m.
New subject: Ooura vs FFTW3, Re: [linux-audio-dev] DRC 2.4.0
On Sat, 2004-02-28 at 17:47, Tim Goetze wrote:
btw, http://www.fftw.org/speed/ paints an altogether
different
picture.
Anyway, speed difference is rather small. FFTW seems to be a bit faster
on Athlon, but which one is faster depends on so many things that it
doesn't make any practical difference which one is used. IMHO.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
5:01 p.m.
On Sat, 2004-02-28 at 16:53, Steve Harris wrote:
Do you have the SIMD optimisations on, and have you
tried the
"halfcomplex" mode of FFTW, thats fine for audio, and saves some memory
i/o.
No, because SIMD optimizations are broken. I've been unable to compile
version which is able to run on all >=i686 platforms and includes 3DNow
&/ SSE stuff. It just crashed on my Thunderbird-core Athlon.
I use *_execute_dft_r2c().
Also SIMD optimizations doesn't do any good on non-x86 architectures
like SPARC, Alpha or HP-PA.
Anyway, I'm going to add some SIMD stuff to Ooura also.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
6:13 p.m.
On Sat, Feb 28, 2004 at 11:57:27 +0200, Jussi Laako wrote:
On Sat, 2004-02-28 at 16:53, Steve Harris wrote:
I've only tried building for particular platforms (various SSE
implementations), but it makes a big difference on PIII and Athlon XP.
- Steve
Do you have the SIMD optimisations on, and have
you tried the
"halfcomplex" mode of FFTW, thats fine for audio, and saves some memory
i/o.
No, because SIMD optimizations are broken. I've been unable to compile
version which is able to run on all >=i686 platforms and includes 3DNow
&/ SSE stuff. It just crashed on my Thunderbird-core Athlon.
6:46 p.m.
[Steve Harris]
On Sat, Feb 28, 2004 at 11:57:27 +0200, Jussi Laako
wrote:
on this 1.7 G athlon it does too, compare this:
[~/audio/src/fftw-3.0.1/tests] ./bench --verify irf1024
[~/audio/src/fftw-3.0.1/tests] ./bench irf1024
Problem: irf1024, setup: 89.29 ms, time: 11.50 us, ``mflops'': 2226.1
where irf = in-place real forward
... to Jussi's 2.4 G celeron:
On Sat, 2004-02-28 at 16:53, Steve Harris wrote:
I've only tried building for particular platforms (various SSE
implementations), but it makes a big difference on PIII and Athlon XP. Do you have the SIMD optimisations on, and have
you tried the
"halfcomplex" mode of FFTW, thats fine for audio, and saves some memory
i/o.
No, because SIMD optimizations are broken. I've been unable to compile
version which is able to run on all >=i686 platforms and includes 3DNow
&/ SSE stuff. It just crashed on my Thunderbird-core Athlon. FFTW3:
43 us / 1024 point complex FFT (single), 23256 FFTs/s, 23.814 MS/s
70 us / 1024 point complex FFT (double), 14286 FFTs/s, 14.629 MS/s
42 us / 1024 point real FFT (single), 23810 FFTs/s, 24.381 MS/s
tim
29 Feb
29 Feb
4:12 a.m.
On Sun, 2004-02-29 at 01:35, Tim Goetze wrote:
on this 1.7 G athlon it does too, compare this:
[~/audio/src/fftw-3.0.1/tests] ./bench --verify irf1024
[~/audio/src/fftw-3.0.1/tests] ./bench irf1024
Problem: irf1024, setup: 89.29 ms, time: 11.50 us, ``mflops'': 2226.1
Here's my Celeron (Fedora Core 1, gcc-3.3.3):
[root@vaarlahti tests]# ./bench --verify irf1024
Segmentation fault
[root@vaarlahti tests]# ./bench irf1024
Segmentation fault
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
8:40 a.m.
[Jussi Laako]
On Sun, 2004-02-29 at 01:35, Tim Goetze wrote:
pity. you've surely filed a bug report?
tim
on this 1.7 G athlon it does too, compare this:
[~/audio/src/fftw-3.0.1/tests] ./bench --verify irf1024
[~/audio/src/fftw-3.0.1/tests] ./bench irf1024
Problem: irf1024, setup: 89.29 ms, time: 11.50 us, ``mflops'': 2226.1
Here's my Celeron (Fedora Core 1, gcc-3.3.3):
[root@vaarlahti tests]# ./bench --verify irf1024
Segmentation fault
[root@vaarlahti tests]# ./bench irf1024
Segmentation fault
4:14 a.m.
On Sun, 2004-02-29 at 01:08, Steve Harris wrote:
I've only tried building for particular platforms
(various SSE
implementations), but it makes a big difference on PIII and Athlon XP.
Possibly, but it's not comparable any more. I like to compare C vs C
implementation if I do compare.
I'll publish the test results when I get SSE2 optimization for Ooura
code done.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
7702
days inactive
7705
days old
linux-audio-dev@lists.linuxaudio.org
17 comments
4 participants
participants (4)
-
Denis Sbragion -
Jussi Laako -
Steve Harris -
Tim Goetze