Software > Coding
gcc, GEMDOS Super und Stackzerstörung
mfro:
--- Zitat von: czietz am Sa 06.08.2016, 17:58:02 ---Aber das Experiment ist ohnehin mehr oder weniger beendet, weil gcc (selbst mit -O2) unglaublich ineffizienten Code generiert. Die "Moving Inversions" in YAART brauchen ca. 50%(!) länger als in der mit Pure C compilierten Version. Darin werden keine Bibliotheksfunktionen aufgerufen, es ist also wirklich der generierte Code.
--- Ende Zitat ---
Das interessiert mich, kannst Du den Code mal zeigen?
czietz:
Ich gucke mal, ob ich den Code soweit herunterbrechen kann, dass ich ihn hier posten kann. Das wird aber nur niedrige Priorität haben, mit Pure C bin ich soweit glücklich, dass ich ehrlich gesagt keine große Energie in Ursachenanalyse mit dem gcc stecken will.
mfro:
--- Zitat von: simonsunnyboy am Sa 06.08.2016, 17:04:19 ---... Geht mit jeder void ...(void) Funktion
--- Ende Zitat ---
Nicht void. Supexec() erwartet eine Funktion, die einen long-Wert zurückgibt. Den serviert sie dann auch dem Aufrufer.
simonsunnyboy:
Offiziell ja, inoffiziell geht es genauso auch gut mit void ;)
czietz:
--- Zitat von: mfro am Sa 06.08.2016, 18:14:58 ---Das interessiert mich, kannst Du den Code mal zeigen?
--- Ende Zitat ---
Anbei eine deutlich reduzierte Version der "Moving Inversions" aus YAART zum Testen. Hier benötigt die gcc-Version immer noch 25% länger als die Pure-C-Version. yrt_tim.prg ist mit Pure C compiliert, yrt_tim.tos mit gcc -O2.
Profiling mit Hatari zeigt, dass sich Pure C deutlich schlauer anstellt, was die Adressen von häufig vorkommenden Speicherzugriffen angeht und sie in ein Adressregister packt. gcc greift auch in einer Schleife jedesmal auf die Adresse direkt zu und braucht so z.B. mit...
move.w $160dc,d0
move.w d0,(a0)+
... viel länger als Pure C mit einmalig initialisiertem A3 und ...
move.w (a3),(a0)+.
6 304 768 Zyklen vs. 3 151 944 Zyklen!
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln