On 21/11/2014 15:34, Joe Taylor wrote:
> Hi Bill and all,
Hi Joe,
>
>> 1) What is the purpose of f77_wisdom.f90 and wisdom.c? I ask because
>> they seem to duplicate functionality that is already available directly
>> from the FFTW3 library in both C and Fortran form via the fftw3.h and
>> fftw3f.f03 include files.
> File fftw3f.f03 is apparently fairly new. It did not exist when last I
> messed around with FFTW wisdom. Probably we can use it now; we made
> wisdom.c because the older wrapper, invoked through f77_wisdom.f90,
> failed on OS X.
OK. I see there are some FFTW3 issues documented around using the wisdom
import functions from Windows DLL code and I wondered if there were
similar problems in non-DLL code like ours. I would not worry about any
changes to the current code to try and use the FFTW defined
import/export declarations in fftw3f.f03 since the combined wsjtx & jt9
will use the C function calls directly. I will look at using the
fftw3f.f03 APIs in the Fortran program that replaces jt9 for standalone
testing.
>
>> 2) I see that you have named the wisdom data file as jt9_wisdom.dat.
>> Looking at the FFTW implementation it would seem that a single wisdom
>> data file for all applications is not a great overhead. The default
>> system wisdom data file (not available on Windows) is named
>> /etc/fftw/{wisdomf,wisdom,wisdoml} and is intended to contain many
>> optimized plan choices for various type and sizes of transform. I would
>> have thought that a single wisdom data file for all WSJT-X programs and
>> utilities would be sufficient. Was your intention to have a different
>> wisdom data file for wsjt and jt9?
> Revision 4617 also reads/writes wsjtx_wisdom.dat. We're presently
> running two processes in parallel, jt9[.exe] and wsjtx[.exe]. We don't
> want them writing to the same file, possibly over-writing information
> that the other process wanted to save.
Good point.
>
> It will be trivial to change to one file if/when we change to a
> single-process model.
Agreed.
>
> System wisdom is convenient in *nix but not very convenient in Windows.
> The whole idea is not particularly useful when we are using oddball
> FFT lengths like some of those used in WSJT-X, e.g., 77175, 672000, and
> 884736.
OK.
>> 3) I was also thinking of adding a header line to the exported wisdom
>> data file including the program version. Something like:
>>
>> version:<last-change-svn-revision>{-dirty,-local}
> Could be done, but my informed guess is that it's not worth the effort.
> These optimizations lead to speed improvements that are rather minor.
> The code is already carefully tuned and optimized; the FFTs do not
> dominate execution times.
Understood. I suggested it partially because you were already
pre-reading the wisdom data file to extract the FFTW wisdom header. I'll
leave it as is.
>
> -- 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
