Lieber keine Optimierungen

Yay! GATE kompiliert auf dem PinePhone unter postmarketOS!

… aber erst nach Anpassungen in der LIBPNG.

Ach, pfeif’ drauf, wer braucht schon NEON

NEON ist einer dieser ge-hype-ten mega-ultra-giga-geilen SIMD (single-instruction-multiple-data) Befehlssatzerweiterungen für ARM Prozessoren.

Solchen Codes ist es zu verdanken, dass ARM Systeme besser und vor allem schneller mit Multimediaaufgaben umgehen können.

Zweifellos sind Audiokonvertierungen oder Videostreams ohne diesen Befehlssatz entweder unmöglich oder CPU-Grillkohlen.

Da das GATE Projekt selbst keine bzw. nur wenig Multimedia-Implementierung beinhaltet, sind solche Erweiterungen eigentlich kein Thema. Sie werden daher nicht eingeschaltet … aber, wie sich herausgestellt hat, auch nicht abgeschaltet.

Der GCC versucht in der Regel alles an Features zu aktivieren ja nachdem, auf welcher CPU er betrieben wird. Kompiliert man auf einem i7, dann hat man i7-Features im Code, so lange man sie nicht explizit abschaltet.

Das gleiche gilt für ARM NEON, und da mein PinePhone diesen Befehlssatz unterstützt, kann dieser beim Kompilieren herangezogen werden.

Blöderweise nutzt die LIBPNG ein paar Makros um dieses Feature zu erkennen und versucht dann eine andere ARM-Assembler Implementierung aufzurufen.

Jetzt war es aber mein erklärtes Ziel, keinen (bzw. so gut wie keinen) Assemblercode im Projekt zu haben, damit keine Spezialfeatures wirksam werden, die nicht auf allen CPUs laufen.
Und genau deshalb sind diese Sourcen der externen Bibliotheken auch nicht mit eingecheckt worden.

Nun, der CMAKE Workaround ist einfach:

add_definitions(-DPNG_ARM_NEON_OPT=0)

ins CMakeLists.txt und schon erkennt LIBPNG den NEON Support nicht mehr. Und da das GATE Projekt die Bibliothek nur für “einfache” Bildkonvertierungen nutzt um Grafiken einzubinden, ist die Performance hier kein Thema.

Schlimmer ist aber die Erkenntnis, dass neben den Plattform-Unterschieden von Linux jetzt auch noch die CPU des Buildsystems den Bau von unabhängigen Binärdateien behindert.

Natürlich wäre es jetzt möglich per CMake allerlei Abschaltungen von Features einzubauen … aber … irgendwann muss man auch hinterfragen, ob das denn Sinn macht.

Eines steht jedoch hiermit wieder mal fest:

Während man für Windows Binaries bauen kann, die von NT 4 bis Windows 10 und vom Pentium 586 bis zum aktuellen AMD Ryzen lauffähig sind, wird das beim GCC ein unguter Hürdenlauf.

PS: Naja … um ehrlich zu sein, auch Microsoft setzt neue Befehlssätze bei neuen Compilern voraus. Doch dort kann ich zumindest mit VS 2005 ein Brücke bauen, die über 20 Jahre Codegeschichte miteinander verbindet.