On 20/11/2014 14:31, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> Yes, there are many possible ways to take advantage of FFTW's wisdom
> capability. I've been using it for some years now -- both for
> professional research purposes and in MAP65, which processes a 96 KHz
> signal bandwidth in each of two polarizations and thus has much higher
> CPU demands.
>
> It's well worth the effort required to implement wisdom, especially with
> large FFTs whose lengths are not powers of two.
No disagreement there.
>
> There's no speed advantage to accumulating wisdom within the executing
> program(s) rather than beforehand. Having it done once at program
> installation has worked well in MAP65. It's true, though, that for
> MAP65 I was not particularly worrying about installers on OS X.
The FFTW manual states the wisdom generated by the initial plan creation
calls in the target executable is more likely to be a better plan choice
because the data alignment is exactly as will be in the plan execution.
This seems to say that using fftwf_wisdom is not always going to choose
the best plan for the sizes and types requested.
So it would seem that using "in program" wisdom generation has potential
to yield faster transforms.
>
> I've implemented wisdom the other way, as well -- which in this case
> means importing/exporting it from within wsjtx[.exe] and jt9[.exe].
> Given your comments about complicating the installers, I'll try doing it
> that way before going on to other things.
Seems to be a win - win scenario for both best performance and simpler
installation. I note we are using "measured" plans, have we tried the
default level of "patient" or even "exhaustive". I would guess that
exhaustive done "in program" might be unwelcome if it turns out to make
the first decode or waterfall "tick" after installation take an hour or
more :(
OK, I see that you include wsjtx.exe in the wisdom import/export
process, make sense as it calls symspec_, but I didn't see a change to
import wisdom in wsjtx. Should wsjtx be doing the import/export as well
(or just import if we are using fftwf_wisdom)?
I assume the overall aim here is to increase the exhaustiveness of the
FFTW plan optimizations to "FFTW_PATIENT" or higher to get the best
possible performance.
On a related note, the FFTW documentation suggests that wisdom should be
regenerated for each new build of an executable, I assume because of the
potential data alignment and virtual memory changes, perhaps we do need
something in the install process to discard the program specific wisdom.
Maybe installing an empty wisdom file somehow although the fact that the
data directory is related to the run instance name complicates matters.
One possible solution is to write the program version into the wisdom
file, that would require using the more complex
fftw_{import_wisdom_from,export_wisdom__to}_file functions that allow
user data to be included in the wisdom file.
>
> -- Joe
73
Bill
G4WJS.
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
