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
