Reverse Engineering der NLT II

[llm]

Was genau möchtest du mir/ uns damit mitteilen?

ohne die Info von dir mit "Die Originalimplementierung dieser Funktion hat mit GCC/Clang falsche Werte geliefert." war einfach nicht klar warum dich diese kleine Routine so interessiert - jetzt sind NewProggie und ich im Bilde

d.h. du hast das für 32/64bit gefixt aber weils im BCC eh ohne Optimierung gebaut wurde hatte der Fehler in der DOS Exe nie Auswirkungen?

zu deinem Benchmark

Code:

Meine Version (-O0, -O1, -O2)
GCC: 94s, 10s, 10s
Clang: 113s, 0s, 0s

Deine Version (-O0, -O1, -O2)
GCC: 29s, 0s, 0s
Clang: 28s, 9s, 0s

die Zahlen kommen mir komisch vor - speziell gcc -02 und clang -01 - der clang (21.1.5) und der gcc (15.2.1) schmeissen bei mir mit -O2 schon den kompletten Code raus und machen nur return 0;
siehe: https://gcc.godbolt.org/z/a6GssaaT1

und für clang(ab -O1)/gcc(ab -O2) ist der code unserer beiden bei Funktionen 100% identisch (der MSVC 2022 reduziert meine Funktion auch auf bswap bei /O2) - nur der Benchmark-Code ist anders optimiert
https://gcc.godbolt.org/z/8rqvY9bjh

Code:

swap32_llm(unsigned int):
        mov    eax, edi
        bswap  eax
        ret

swap32_hen(unsigned int):
        mov    eax, edi
        bswap  eax
        ret

main:
        xor    eax, eax
        ret

damit "wissen" der gcc und clang das dein if nie anschlagen wird, also kann man alles weg optimieren

bei sowas musst du meist Sondervariable mit einfügen - damit der Optimizer die Finger still hält - UND den Assembler-Code anschauen

eher sowas wie

Code:

int main() {
  int x = 0;

  for (uint32_t i = 0; i < 0xffffffff; i++) {
    x += swap32_llm(i);
  }

  return x;
}

aber da beiden Funktionen identisch sind nach der Code-Generierung macht hier Benchmarking nicht so viel Sinn weil man dann nur den Benchmark-Code benchmarkt

und du solltest deinen gcc/clang mal updaten

der aktuelle MSVC 2022 schafft es nur meine Routine in den einfach swap zu wandeln - deine Routine bleibt etwas umfangreicher
https://gcc.godbolt.org/z/bW8vxc3Wz

aber VS2022 schafft es auch nicht mit dem einfachen swap (also dem wissen darum) auf return 0 zu optimieren
was man aber auf keinen Fall als gcc/clang machen immer den bessere Code interpretieren sollte - die Final-Optimierung bei solchen Dead-Ends ist beim gcc/clang einfach besser - aber haben nicht immer Auswirkung auf echte Software

manchmal rasten auch die Optimizer vom gcc/clang aus (hab da schon genug Bug Reports eingestellt oder Diskussionen) gehabt wo der sich ergebende Code auch nicht mehr so fein war

Entscheident sind die richtigen Werkzeuge(VTune unter Windows/Linux, gcc.godbolt.org sind die Welt-Favoriten)/Strategien zum Benchmarking, aktuelle Kompiler und keine ausgeprägte "so war das mal" Denke
Es ändert sich in den letzten 10 Jahren erstaunlich viel, erstaunlich schnell als das Erfahrungswerte nicht einer deutlichen Auffrischung benötigen - das gilt für jeden Entwickler

aber es zeigt auf jeden Fall wie gut die Optimizer arbeiten können