[pskmail] Re: Testing of faster modes
- From: John Douyere <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Tue, 28 Feb 2012 10:07:53 +1100
Hello Remi,
Yes I had to do a fair bit if optimisations to fit all the modes into a
phone's CPU's capabilities.
For information Rein and I (and another OM before us) translated some of
the Fldigi modems into Java.
I had two options when developing on Android: Java code or Native
development in C++ with hooks back and forth between the Java part and the
C++ part.
Development time wise the C++ path was probably the fastest but then each
version of CPU needs to have it's compiled version and I didn't want to be
in that position spending a lot of my time playing catch-up with the latest
device/CPU version.
Also I knew that the JIT compiler in Java was reported to bring good speed
improvements over the raw code as it dynamically optimises the code based
on real-time CPU load. And it certainly did bring well over 2 x speed
improvements on the same device for these CPU intensive tasks like the
modems processing, especially from Android version 2.3 onwards.
So in the end I will stay with the Java overhead especially that new dual
and quad core CPUs found in these devices are now very capable.
But at the same time the new modes I am working on will most likely bring
extra CPU load as well...so it is a never ending story..hihi
In that regard the speed improvements you are talking about are always
welcomed. It is not a major task to translate them back from C++ to Java.
On the Android version there is a basic profiler and the results are that
most of the processing is done in the FIR filters run for PSK modes. For
the PSKR modes it is first the (de)interleaver, then in the FIR filters.
So any improvement on the FIR filters run would be a plus. In the "slow
CPU" option I have in the software, I reduced the number of taps of the FIR
filter by half among other things. That produces a slightly larger passband
but it is not really an issue for Pskmail in practice (not like when using
PSK31 in a crowded band).
I also have made the waterfall a temporary feature in the sense that it has
to be called on and then it disappears when moving away from the modem
screen in order to save processing power.
I also reused the FFT processing of the RSID RX modem for the waterfall so
that I don't double up on FFTs (we always have RSID RX ON in the Pskmail
client).
The other point also is that there are no pointers in Java which means that
array processing is slower (unless maybe the JIT compiler takes care of
this which would explain some of the processing gains).
So I would welcome any ideas for speeding up the FIR filters and the
interleavers used in the PSKR modes.
Thanks.
73, John
On Tue, Feb 28, 2012 at 9:00 AM, remi.chateauneu@xxxxxxxxx <
remi.chateauneu@xxxxxxxxx> wrote:
> Hi John,
>
> Thanks for the answer.
> This question because there are a couple of speedups (i.e. lower power for
> the same task) which are possible in fldigi. There are not really worth for
> a desktop but might make a difference for a portable computer.
>
> Here are the hungriest function of a run I am working on at the moment. I
> removed everything related to my specific modem (The first column is the
> number of non-cumulated calls):
>
> 893,482,434 src/waterfall/waterfall.cxx:**WFdisp::update_waterfall()
> [/home/rchateau/RadioAmateurs/**FlDigiMaster/fldigi/src/**fldigi]
> 848,167,248 src/fft/fft.cxx:Cfft::cftmdl(**int, int, double*)
> 659,570,688 src/./include/filters.h:C_FIR_**filter::run(complex&,
> complex&)
> 346,500,805 src/waterfall/waterfall.cxx:**WFdisp::processFFT()
> 285,200,070 src/fft/fft.cxx:Cfft::cft1st(**int, double*)
> 256,435,761 ???:memmove [/lib/i686/libc-2.7.so]
> ...etc...
>
> I believe there is room for improvement, apart from the Cfft function whih
> seem to be really well tuned (But compiler flags might help ?). Ideally we
> would need a profiler report (gprof, callgrind) of a typical AndPskmail
> execution. How often do you merge your version with the main branch ?
>
> Cheers
>
>
Other related posts:
