Я наткнулся на очень странную проблему с G CC. Проблема в снижении производительности на 25%. Вот история.
У меня есть кусочек программного обеспечения, интенсивно использующего fp32 (нейронные сети скомпилированы с TVM). Я скомпилирую его для ARM (устройство rk3399), вот информация:
g cc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.12' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.12)
uname -a
Linux FriendlyELEC 4.4.143 #1 SMP Tue Nov 20 11:10:11 CST 2018 aarch64 aarch64 aarch64 GNU/Linux
lscpu
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 6
On-line CPU(s) list: 0-5
Thread(s) per core: 1
Core(s) per socket: 3
Socket(s): 2
Model name: ARMv8 Processor rev 2 (v8l)
CPU max MHz: 1800.0000
CPU min MHz: 408.0000
Hypervisor vendor: horizontal
Virtualization type: full
Код изначально был "медленный" и cpp11, я решил попробовать cpp17 и cpp14. cpp17 не был поддержан, но cpp14 был. Я переключился на cpp14 и вуаля я получил повышение примерно на 25% в производительности. Я действительно проверил это, чтобы убедиться, что повышение действительно реально, а не ошибка измерения. У меня было это повышение в течение недели, затем мое устройство перезагрузилось, и повышение производительности исчезло!
Это может звучать странно, но я очень уверен в своем коде и измерениях, которые у меня были. У меня не было явных флагов компиляции до этого трюка. Сейчас я пытаюсь выяснить флаги компиляции для G CC, чтобы восстановить то, что было потеряно, но у меня нет большого опыта работы с G CC. В чем может быть проблема здесь? Какие флаги могут так сильно повлиять на производительность?
код использует файлы .so, скомпилированные с использованием llvm и g cc
llvm -device=arm_cpu -target=armv8l-linux-gnueabihf -mattr=+neon,fp-armv8