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