Hi Pavel and all - I spent some time this weekend to check out your patch to the experimental wspr decoder. I was able to confirm your observation of a worthwhile speedup on my Intel cpu.
I also did some more tests to compare the patched wsprd_exp with the stock decoder wsprd. These tests showed that wsprd_exp produced more good decodes but also more false decodes than wsprd. I found that raising the metric-table bias to 0.45 from 0.42 lowered the false-decode rate of wsprd_exp to the same level as that of the current wsprd. Even with this change, wsprd_exp still produces more decodes than wsprd. After making the changes described above I did a final set of runs on three different batches of files. For each run I recorded the number of good decodes, the number of bad decodes containing a “/“ because those are easy to find and count, and total execution time from wspr_timer.out. The results are summarized below in this order: sF: wsprd (Fano algorithm, max 10000 cycles) eF: wsprd_exp (Fano algorithm, max 10000 cycles) eJ: wsprd_exp -JC 5000 (Jelinek algorithm, max 5000 cycles) In the following, the number in parentheses is the number of bad decodes that contain “/“ (because these are easy to find and count): 1. k9an wav files from 8-channel SDR - 1953 files, all bands sF: 5080 (1), 984s eF: 5162 (0), 862s eJ: 5160 (1), 811s 2. k9an c2 files from TS-480 - 258 files, all bands sF: 1132 (0), 165s eF: 1144 (0), 150s eJ: 1141 (0), 137s 3. k1jt wav files - 410 files sF: 2655 (0), 329s eF: 2728 (0), 319s eJ: 2718 (0), 300s In view of the fact that wsprd_exp is faster than wsprd, produces more decodes than wsprd, and maintains the low false-decode rate of wsprd, I have committed a change that makes the patched (float) version of wsprd_exp.c the default decoder. The default setting is to use the Fano-algorithm for decoding. The command-line setting -J can be used to switch to the Jelinek stack-bucket decoder. This change has been committed as r6572. I should note that I also took this opportunity to fix a long-standing inconsistency in the way that the time-offset, dt, has been reported by the wspr decoders. Until now, the decoders have all reported the time offset relative to 2 seconds after the beginning of the file. Since wspr transmissions start at 1 second after the minute, the dt has traditionally been reported as -1 seconds for a transmitter-receiver pair with the same clock time. Beginning with r6582, the dt is reported relative to 1 second after the beginning of the file, and should be near zero for a transmitter-receiver pair with the same clock time. Steve k9an > On Mar 30, 2016, at 2:26 PM, Pavel Demin <[email protected]> wrote: > > Hi Joe, > > Thank you for confirming that switching to floats should be relatively safe. > > I started to use wsprd_exp after reading the following threads on this > mailing list: > https://sourceforge.net/p/wsjt/mailman/message/34326507/ > https://sourceforge.net/p/wsjt/mailman/message/34334059/ > > Looks like wsprd_exp already worked very well more than six months ago > and wsprd_exp -J produced more decodes than wsprd. > > Since I'm running wpsrd_exp on a small embedded system (Red Pitaya) and > decoding eight WSPR bands simultaneously, other factors like simple > installation and high performance are also important for me. > > Out of the box, wpsrd_exp is more than 20% faster than wpsrd on my > system and I can easily install wpsrd_exp (but can't wpsrd) with just > two commands: > svn co svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx/lib/wsprd > make -C wsprd CFLAGS='...' wsprd_exp > > All in all, the experimental status of the wsprd_exp code fits very well > the experimental status of my multiband WSPR receiver and I'm having a > lot of fun with both :-) > > Best regards, > > Pavel > > Joe Taylor wrote: >> Hi Pavel and all, >> >> Thanks for your effort on optimizations in wsprd. The change from >> doubles to floats has been on our "To Do" list for many weeks. We >> didn't get around to it because the potential gains (though desirable) >> were not likely to be huge. Floats have enough precision for use in all >> the long arrays. >> >> Is there a reason why you worked with wsprd_exp rather than wsprd? Our >> "production code" is wsprd; wsprd_exp is an experimental version that >> uses the "Jelinek" rather than "Fano" algorithm for sequential decoding >> of the convolutional code. >> >> -- Joe, K1JT >> > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
