Performance enhancements for DREAM on KiwiSDR?
Somebody told me on Twitter that my FEC software decoders are now used in three separate places in the KiwiSDR: reading satellite navigation messages, decoding WSPR transmissions and now in the DRM30 decoder. Cool; I didn't know this before. Always nice to know it's of use.
How is performance? Since the Beaglebone has an ARM CPU, it can't benefit from all the work I did using the Intel/AMD x86 SSE vector instructions to speed up my Viterbi decoder. Ergo, you must be using my portable implementation in C, which is much slower (on the x86) than the vectorized version. On the other hand, the data rates in GNSS and DRM are so slow that this may not make much difference.
Can anybody comment on whether a version of my Viterbi decoder for the ARM Neon vector set would be worthwhile? Thanks.
How is performance? Since the Beaglebone has an ARM CPU, it can't benefit from all the work I did using the Intel/AMD x86 SSE vector instructions to speed up my Viterbi decoder. Ergo, you must be using my portable implementation in C, which is much slower (on the x86) than the vectorized version. On the other hand, the data rates in GNSS and DRM are so slow that this may not make much difference.
Can anybody comment on whether a version of my Viterbi decoder for the ARM Neon vector set would be worthwhile? Thanks.
Comments
I haven't done any serious performance measurement on the DRM code yet, except to determine that the Viterbi stuff was taking less than 7% of the time for the particular DRM configuration used by my test recording. It's quite possible it would be more significant in other cases.
I did a quick check a few weeks ago and found some Neon Viterbi implementations on Github. So at some point I may look at those.
What made DRM work on the Kiwi/Beagle was throwing the switch from using doubles everywhere to floats, lol. Fortunately, the way that code was written, it was a single change in a header file.