Hi Clemens & Pavel,
The decoder has a “quick” mode that is activated with the -q command-line
option. Have you tried that?
Steve k9an
> On Mar 15, 2016, at 8:34 AM, Bill Somerville <[email protected]> wrote:
>
> On 15/03/2016 12:48, Clemens Heese wrote:
>> The only thing is, it takes an awful lot of time: real 2m55.589s
>> I pass the CFLAGS to the compiler via:
>>
>> cmake -D CMAKE_BUILD_TYPE=Debug -D
>> CMAKE_INSTALL_PREFIX=/root/src/wsjt/src/build/Debug/ -D
>> CMAKE_C_FLAGS=-I/usr/include -Wall -Wno-missing-braces -O3 -march=armv7-a
>> -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard -ffast-math -D
>> CMAKE_PREFIX_PATH=/root/src/hamlib /root/src/wsjtx/src/
>>
>> Is this the way of doing it? Why is it so slow (also without the DEBUG
>> option real 2m11.681s)? Pavel Demin does the same interestingly in ~10sec
>> on the same cpu. I have no clue why he does not see the bug!
> Hi Clemens & Pavel,
>
> We do not really claim the that the WSPR decode is particularly efficient,
> after all we have a full two minutes to complete the search for decodes.
> Clearly more than two minutes is an issue. What is your target platform,
> particularly the CPU speed? is there anything else running on the machine?
> What desktop, if any, are you running? We may need to do some profiling to
> find the best place to optimize for speed.
>
> To append options for the compilers you can use the normal CFLAGS and
> CXXFLAGS variables by setting them in the environment for CMake
> configuration. You must be careful to use a full configuration when you amend
> these variables, the best way to do that is to delete the CMakeCache.txt
> file. I.e.
>
> rm CMakeCache.txt
> CFLAGS="-Wno-missing-braces -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9
> -mfpu=neon -mfloat-abi=hard -ffast-math" \
> CXXFLAGS="$CFLAGS" \
> cmake -D CMAKE_INSTALL_PREFIX=/root/src/wsjt/src/build/Debug/ \
> CMAKE_PREFIX_PATH=/root/src/hamlib\
> /root/src/wsjtx/src
>
> Sometimes -O3 is too aggressive and can reveal problems, I suggest you allow
> CMake to choose the optimization level. Tuning for your specific hardware is
> fine.
>
> The FFTW3 library build may be a factor although I would have thought that
> the distribution package maintainer would have chosen the best options for
> the system.
>
> The bug was subtle with a buffer overrun corrupting the stack, as the
> corrupted variable was a procedure argument it would normally be in a
> register but the compiler chose to spill it onto the stack as it needed the
> register for computation. Register spills are very optimization level
> dependent and architecture dependent so any small CPU or compiler flags
> change could make the difference.
>
> 73
> Bill
> G4WJS.
> ------------------------------------------------------------------------------
> 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=278785231&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=278785231&iu=/4140
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
