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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel