I'm trying to (cross)compile the BRP-App for AARCH64.
I simply modifyed the LINUX-ARMv7NEON-XCOMP-Part (too lazy to implement a extra funtion for AARCH64 ;) ) in Build.sh.
Replacing (set_arm_xcomp() Line 316-318):
export CC=arm-unknown-linux-gnueabi-gcc export CXX=arm-unknown-linux-gnueabi-g++ export LD=arm-unknown-linux-gnueabi-ld
with:
export CC=aarch64-linux-gnu-gcc export CXX=aarch64-linux-gnu-g++ export LD=aarch64-linux-gnu-ld
modifyed the CXX- and C-FLAGS (under $TARGET_LINUX_ARMV7 Line 1693-1694) from:
export CXXFLAGS="-march=armv7-a -mfpu=neon -mfloat-abi=hard $CXXFLAGS" export CFLAGS="-march=armv7-a -mfpu=neon -mfloat-abi=hard $CFLAGS"
to
export CXXFLAGS="-march=armv8-a -mcpu=cortex-a53+simd $CXXFLAGS" export CFLAGS="-march=armv8-a -mcpu=cortex-a53+simd $CFLAGS"
and finally removed the --enable-neon from Functions build_fftw() on Line 764 and build_fftw_ndk()on Line 803.
Because the AARCh64-gcc doesn't know this Option. Neon should be enabled by default.
After modifying that, the build can be almost done, except the last Step:Building Binary Radio Pulsar Search [Application]...
this gives me an Error:
/home/osboxes/BRP64/src/erp_boinc_wrapper.cpp:180: undefined reference to `backtrace_symbols_fd_plus' collect2: error: ld returned 1 exit status Makefile:73: recipe for target 'einsteinbinary_arm-unknown-linux-gnueabihf' failed make: *** [einsteinbinary_arm-unknown-linux-gnueabihf] Error 1
The function backtrace_symbols_fd_plus is defined in erp_execinfo_plus.h & erp_execinfo_plus.cpp. So I think there is an Error in compiling these Files.
Are there any other Logfiles or something similar where I can see what causes these Error?
P.S. The rest of the Output in build.log are the same as the build.log when successful compiled for ARMv7.
Copyright © 2024 Einstein@Home. All rights reserved.
Compiling BRP for AARCH64-Linux
)
Update:
The Problem is only this one function-call backtrace_symbols_fd_plus in erp_boinc_wrapper.cpp:180.
If I comment this line out, the compile is successfull.
You can comment out all the
)
You can comment out all the erp_ files. they are not needed for the scientific part.
Interesting
)
Interesting project.
I think you should keep the "--enable-neon": this is not an argument to gcc but to FFTW's configure script.
Some other things to consider:
The build script uses FFTW 3.3.2 . For the ARMv7 devices I've seen so far, this version gives the best performance. But for ARMv8, you might want to try FFTW 3.3.4, the latest version. Look for "3.3.2" in the build script and change accordingly.
Once you get this running, you can toy around with generating FFW wisdom for your specific host (see http://www.fftw.org/doc/Words-of-Wisdom_002dSaving-Plans.html ) to get better performance. The utility program that is used for this is generated alongside the BRP app in
install/bin/fftwf-wisdom
below the directory of the build script.
First Task's are running :)
)
First Task's are running :) :) :) Hopefully the results become valid.
Here is the Link to the Computer https://einsteinathome.org/host/12232054
No, im running into an Error keeping this argument. Because the configure-script only set's CFLAGS="-mfpu=neon". Maybe I have to modify the configure-script of FFTW. Or try a newer Version of the FFTW-lib at first.
Thanks for suggestion. I will give it a try.
After the first result's are valid I try to optimize the App using your suggestions.
P.S. Only for my personal interest what does Wisdom to optimize the FFT?
Asking because I have build a 8-Band-Spectrum-Analyzer for Audio Purpose around 2 years ago. With logarithmical X-Axis & Y-Axis from 31,5Hz to 16Khz(8-Octaves).
Using only a 32Mhz 8bit CPU for calculating the FFT and reached an Updatespeed of >12Hz.
I think that is really fast(for that CPU) but more is better :P and maybe I can optimze it a little bit.
RE: RE: I think you
)
No, --enable-neon will also set the HAVE_NEON macro which does tons of things in FFTW compilation, so you are most likely now running a version that does not use the NEON vector FPU.
As far as I can see, the problem you ran into when compiling for AARCH64 was fixed only after the latest version of FFTW was released (3.3.4), but it is in the current development git, master branch, see https://github.com/FFTW/fftw3. Must be this change: https://github.com/FFTW/fftw3/commit/8aa91763af07767f3ebb71a9836a69e3b3385cab. It adds double precision FFT for AARCH64 (not needed for BRP) and also makes other adjustments for AARCH64 gcc .
Think of FFTW "wisdom" as recorded profiling results that will help FFTW to pick the best way to compute a given transfrom, selecting one of the many variants how to compute it.
RE: First Task's are
)
Congratulations, some results have validated and took between ca. 48k and 52k. That is OK but not great, a PI3 can do this in ca 38k sec, e.g. https://einsteinathome.org/host/12212487/tasks&offset=0&show_names=0&state=4&appid=, I guess with some modification to the FFTW build scripts as discussed above, you would be able to get better performance with NEON.
What kind of machine is this, anyway? An Odroid C2? I would not be surprised if a C2 could do BRP tasks in, say, 25k sec.
Thanks :), yes it's an
)
Thanks :), yes it's an ODROID-C2.
Unfortunately I can't get FFTW to work with the actual Master-Branch from GIT. With 3.3.4 it worked without any issues, but without NEON.
But the version from GIT gives me errors on ./configure
I really don't know why, have tried many different thinks, nothing worked. But for today it's enough for me. My Linux-Terminal has burned into my Eyes and I can see it if I close them ;P.
I would try to go with 3.3.4
)
I would try to go with 3.3.4 and just apply the patch I mentioned above, or maybe even the part that deals with configure (basically delete the test that checks that gcc takes -mfpu=neon when --enable-neon is selected. Maybe that already helps.
RE: basically delete the
)
Only trick the ./configure don't work, for doing this I don't have to manipulate it. Simple adding NEON_CFLAGS="-D__ARM_NEON__" to the end of the ./configure-call makes it.
But I'm running into many Error's. All from header-files that containing "neon" in her name. I try to switch the simd-neon.h to the changed one from git-repository. Maybe that helps.
Don't get it to work :(. Have
)
Don't get it to work :(. Have tried to apply the patch from GIT-hub manually, tried to manipulate the configure-script. Nothing worked.
And now I can't think any further myself. :(
Here's the make-log ([....]-reduced):
Any suggestions how to fix that?