octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: rfftw slower than fftw for "bad" size arrays]


From: David Bateman
Subject: Re: [Fwd: Re: rfftw slower than fftw for "bad" size arrays]
Date: Sun, 1 Feb 2004 04:51:08 +0100
User-agent: Mutt/1.4.1i

According to Dmitri A. Sergatskov <address@hidden> (on 01/30/04):
> I have not tried the patch yet, but I run benchmarks from fftw2 and fftw3
> packages(see below). It seems this problem is the fftw3 "feature" -- when 
> run with
> ESTIMATE flag it does it slower (sometimes) than fftw2.

Yeah, I got this opinion too, and my solution was ....

> 
> It is not quite clear to me from the docs if using "wisdom" created with
> more "patient" flags helps when you use ESTIMATE flag. It is definitely
> possible:

to implement wisdom importing into octave. This seems to work
brilliantly.  You might prefer the patch below. Though its not quite
ready to go into the main tree yet since I have the questions.

1) Should we dump FFTW 2.1.5 
  1a) If not should I try to import a wisdom file from a default place, since
     as I do for 3.0.1. However 2.1.5 doesn't have the concept of system
     wide wisdom
2) What about if there is a problem with the imported wisdom? Should a means
 of making octave forgot FFTW wisdom be implmemented? How?

> One possibility is to have say "make wisdom_measure" rule in octave makefile
> which will create wisdom file (it will take a while, so it should not be in
> default make, I would guess).

in FFTW 3.0.1 the technique is "fftw-wisdom -v -c -o /etc/fftw/wisdom"
and then go away for the weekend. On my machine this took 12 hours, to
generate the powers of 2 and 10 upto 2^20. So I would definitely not
make this a requirement.

Basically, the only case I'm not faster on against matlab just with
this canonical wisdom is the fft(513x513) case. If I then run
"fftw-wisdom -v -o /tmp/wisdom rof513 rof513x513" and import the
wisdom with

octave:1> fft("/tmp/wisdom")

as implemented in the attached patch, then even this is faster than
matlab......

Cheers
David

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

Attachment: patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]