Hallo Flugies,
ich hab ein Problem mit einer Regression. Bin auf ein neues SDK (Arm, yocto) umgestiegen und mein Programm (eine loop die ein großes Byte-Arrays aufsummiert) ist auf einmal deutlich langsamer. (Makefile, Quelle, Optimierung alles gleich).
Es liegt soweit ich sehen kann nur am binary, dem Testprogramm, bzw wie es compiliert wurde. Es scheint nicht am Kernel oder am rootfs zu hängen. Also altes binary auf neuem System ist schnell. Neues binary auf altem System: langsam...
Für mich sieht das so aus als würde der alte Compiler besser optimieren (NEON nutzen, z.B.) und der neue nicht.
Jetzt frage ich mich: was vom SDK/Compiler steckt alles im Binary und kann die Ursache sein. Als erstes fällt einem der GCC selbst ein.
Den habe ich getauscht, aber ohne gewünschtes Ergebnis.
Mit "strings" auf die Binaries angewendet sieht man weitere Unterschiede in gnu-as (binutils ?) und glibc. Es könnte aber auch weitere Unterschiede geben, wenn sich im SDK Software nur im Patchlevel unterscheidet.
glibc selbst ist ja nicht statisch eingelinkt, würde ich ausschließen.
Große Frage: Was könnte es ausser einer Problem im gcc selbst noch sein? Was ist bspw. für optimierten memory-Zugriff zuständig? Den Kernel baue ich nicht mit Yocto, aber evtl trifft der Compiler eine Annahme über irgendein fancy feature dass aber mit meinem nicht vorhanden ist? Wie komme ich der Sache auf die Schliche? Ideen?
Gruß, Arno
PS: Ein neues SDK zu dauern dauert bei mir ein paar Stunden. GCC hatte ich schon probiert, heute Nacht kommen noch die alten binutils dazu. Falls das nichts hilft weiß ich nicht so recht weiter.
On 11/24/22 18:41, Arno Steffens wrote:
Hallo Flugies,
ich hab ein Problem mit einer Regression. Bin auf ein neues SDK (Arm, yocto) umgestiegen und mein Programm (eine loop die ein großes Byte-Arrays aufsummiert) ist auf einmal deutlich langsamer. (Makefile, Quelle, Optimierung alles gleich).
Es liegt soweit ich sehen kann nur am binary, dem Testprogramm, bzw wie es compiliert wurde. Es scheint nicht am Kernel oder am rootfs zu hängen. Also altes binary auf neuem System ist schnell. Neues binary auf altem System: langsam...
Für mich sieht das so aus als würde der alte Compiler besser optimieren (NEON nutzen, z.B.) und der neue nicht.
Jetzt frage ich mich: was vom SDK/Compiler steckt alles im Binary und kann die Ursache sein. Als erstes fällt einem der GCC selbst ein.
Den habe ich getauscht, aber ohne gewünschtes Ergebnis.
Ich würde mal perf bemühen um rauszuknobeln was das neue Compilat langsam macht.
Liebe Grüße Uwe
Am 25.11.22 um 09:02 schrieb Uwe Kleine-König:
On 11/24/22 18:41, Arno Steffens wrote:
Hallo Flugies,
ich hab ein Problem mit einer Regression. Bin auf ein neues SDK (Arm, yocto) umgestiegen und mein Programm (eine loop die ein großes Byte-Arrays aufsummiert) ist auf einmal deutlich langsamer. (Makefile, Quelle, Optimierung alles gleich).
Es liegt soweit ich sehen kann nur am binary, dem Testprogramm, bzw wie es compiliert wurde. Es scheint nicht am Kernel oder am rootfs zu hängen. Also altes binary auf neuem System ist schnell. Neues binary auf altem System: langsam...
Für mich sieht das so aus als würde der alte Compiler besser optimieren (NEON nutzen, z.B.) und der neue nicht.
Jetzt frage ich mich: was vom SDK/Compiler steckt alles im Binary und kann die Ursache sein. Als erstes fällt einem der GCC selbst ein.
Den habe ich getauscht, aber ohne gewünschtes Ergebnis.
Ich würde mal perf bemühen um rauszuknobeln was das neue Compilat langsam macht.
Liebe Grüße Uwe
Vielen Dank Uwe. perf und nötige libs sind noch zu compilieren. Hab ich noch nie benutzt. Wird Zeit das nachzuholen. Wenn ich so darüber lese - perf trace wäre wahrscheinlich am sinnvollsten, oder?
Na ich schau erst mal, aber auch die Daten muss man erst mal richtig interpretieren können.
Gruß, Arno
Am 25.11.22 um 09:02 schrieb Uwe Kleine-König:
On 11/24/22 18:41, Arno Steffens wrote:
Hallo Flugies,
ich hab ein Problem mit einer Regression. Bin auf ein neues SDK (Arm, yocto) umgestiegen und mein Programm (eine loop die ein großes Byte-Arrays aufsummiert) ist auf einmal deutlich langsamer. (Makefile, Quelle, Optimierung alles gleich).
Es liegt soweit ich sehen kann nur am binary, dem Testprogramm, bzw wie es compiliert wurde. Es scheint nicht am Kernel oder am rootfs zu hängen. Also altes binary auf neuem System ist schnell. Neues binary auf altem System: langsam...
Für mich sieht das so aus als würde der alte Compiler besser optimieren (NEON nutzen, z.B.) und der neue nicht.
Jetzt frage ich mich: was vom SDK/Compiler steckt alles im Binary und kann die Ursache sein. Als erstes fällt einem der GCC selbst ein.
Den habe ich getauscht, aber ohne gewünschtes Ergebnis.
Ich würde mal perf bemühen um rauszuknobeln was das neue Compilat langsam macht.
Liebe Grüße Uwe
2 Days later: Also mit/aus perf bin ich nicht wirklich schlau geworden. Um damit besser zu arbeiten hab ich das Durchschnitts-Berechnen extrahiert und damit mit beiden SDKs gleiche Zeiten gehabt! Wenn ich im Original den Buffer erst kopiere und dann darauf Rechne ist nur das Kopieren unterschiedlich schnell. Die Ursache scheint der Buffer selbst. Bei mir ist es ein V4L Buffer der mit V4L2_MEMORY_FLAG_NON_COHERENT einen flotten Zugang aus dem Userspace ermöglichen soll. (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...). Warum das jetzt aber nicht mehr funktioniert - und wie das mit dem Compiler bzw dessen Umgebung zusammenhängt (denn die Laufzeit-Umgebung ist egal) - keine Ahnung. Das wird nicht leicht herauszufinden.
Aber wer natürlich allgemein weiß, wass zur Compiletime alles eine Rolle spielt, das wäre natürlich willkommen um das einzugrenzen. Ein besseres WE an euch, Arno