[Clam-devel] playing with fftw3 wisdom

Roman Goj roman.goj at gmail.com
Mon Jun 11 03:32:37 PDT 2007


I finally started fooling around with CLAM's code (yay!). I've got a
better feeling now of how the chord extraction works and to try to
improve something at least a bit I started hacking at the first thing
that seemed more than just vaguely familiar - the fftw3 code :)

Correct me if I'm wrong (and I probably am...) - to make CLAM use
fftw3 and not the other fft implementations I should just change the
"# clam_processing options" lines in the SConstruct to say yes for
'with_fftw3' ... there's probably a nicer way to do it, right?

What I wanted to try was to see how the fftw3 works (I actually
thought it was the default fft algorithm after the recent posts here)
and it really does improve the performance nicely :) I'm not sure -
but have you also tried doing longer computations for the fftw_plan?
with FFTW_EXHAUSTIVE instead of FFTW_ESTIMATE? The plan itself on my
slow computer takes about an hour to compute, but the efficiency of
the chord extractor increases by 20% ... so I thought - why not save
the plans for fftw? So I wrote the code for saving the plan (wisdom as
it's called by fftw)... while realizing that this is not the way to
go, since the wisdom should either be saved some place global or
(maybe better yet) in the place CLAM gets installed by the user. So
there should probably also be an additional utility for computing the
wisdom after installation/compilation so that it's done only once and
then reused for subsequent calls of FourierTransform.

So the patch I am attaching should probably not be applied, because it
saves the wisdom in the folder the application is called from. But the
question is should I try to make this work well (it does improve
efficiency) or not for now?

I also tweaked a *little* bit the code for ChordExtractor - I wanted
to see how long it takes to compute the extraction itself, but just
removing the comments from the lines with clock_t start and end etc.
didn't help (the start and end were defined outside of where they were
later called to show the time that passed), so I separated the
declaration from assigning the clock() output and left it commented
out (as it was before), but after uncommenting it works nicely, so
maybe they should be uncommented? :)

So maybe I should make this a separate patch (since it's ready to be
applied) to have the First Patch Burden off my shoulders...? ;) OK,
correction, I did this already, sending two patches.

Also - another thing - do you use any profilers for checking which
parts of the code take most time? I wanted to try this, but for now
dropped the subject in favour of tweaking fftw, but do you have any
advice on profiling CLAM?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: using_fftw3_wisdom.patch
Type: text/x-diff
Size: 2315 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070611/4b8339f6/attachment-0006.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ChordExtractor_processing_time_correction.patch
Type: text/x-diff
Size: 956 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070611/4b8339f6/attachment-0007.patch>

More information about the clam-devel mailing list