Frage an die Compilerbauer

[Ingo L. (corrtexx)]

Hallo,

ich habe folgenden Testcode:

#include <avr/io.h>

volatile uint16_t Temp,Temp2;

int main(void)
{
    while(1)
    {
    Temp++;
    asm volatile ("NOP");
    Temp2 = Temp * 60;
    asm volatile ("NOP"); 
    }
}

Bei den unteschiedlichen Optimierungsstufen erhalte ich folgende 
Ausführungsgeschwindigkeiten im Simulator des aktuellen Atmel Studios.

Oo = 22 Takte
O1 = 24 "
O2 = 22 "
O3 = 22 "
Os = 98 "

Warum ist das jetzt bei Os so viel mehr? Die Breakpoints sind jeweils 
bei den NOPs gesetzt.



Ingo

[Peter II (Gast)]

Ingo Less schrieb:
> Warum ist das jetzt bei Os so viel mehr?
einfach mal den ASM-Code anschauen.

> Die Breakpoints sind jeweils
> bei den NOPs gesetzt.
da bei der Optimierung auch die Reihenfolge geändert werden kann, können 
die breakpoints jetzt an anderer stelle liegen.

[Dennis S. (eltio)]

Ich kenne die Antwort nicht, aber wenn ich vor der gleichen 
Fragestellung stehen würde, würde ich mir den erzeugten Assemblercode 
ansehen.

Gruß
Dennis

[SF6 (Gast)]

Ingo Less schrieb:
> Warum ist das jetzt bei Os so viel mehr?
Bei -Os (Optimize space usage) versucht der Compiler wo geht Daten- und 
Programmspeicher zu sparen, das kann wie du gesehen hast auch dazu 
führen, dass das Programm langsamer wird.

[Ingo L. (corrtexx)]

Bei Os wird die <__mulhi3> aufgerufen währen bei den anderen Stufen dies 
wohl nicht erfolgt.

O2:

    Temp2 = Temp * 60;
  58:  20 91 60 00   lds  r18, 0x0060
  5c:  30 91 61 00   lds  r19, 0x0061
  60:  c9 01         movw  r24, r18
  62:  82 95         swap  r24
  64:  92 95         swap  r25
  66:  90 7f         andi  r25, 0xF0  ; 240
  68:  98 27         eor  r25, r24
  6a:  80 7f         andi  r24, 0xF0  ; 240
  6c:  98 27         eor  r25, r24
  6e:  82 1b         sub  r24, r18
  70:  93 0b         sbc  r25, r19
  72:  88 0f         add  r24, r24
  74:  99 1f         adc  r25, r25
  76:  88 0f         add  r24, r24
  78:  99 1f         adc  r25, r25
  7a:  90 93 63 00   sts  0x0063, r25
  7e:  80 93 62 00   sts  0x0062, r24

Os:

  Temp2 = Temp * 60;
  58:  80 91 60 00   lds  r24, 0x0060
  5c:  90 91 61 00   lds  r25, 0x0061
  60:  6c e3         ldi  r22, 0x3C  ; 60
  62:  70 e0         ldi  r23, 0x00  ; 0
  64:  06 d0         rcall  .+12       ; 0x72 <__mulhi3>
  66:  90 93 63 00   sts  0x0063, r25
  6a:  80 93 62 00   sts  0x0062, r24

Speicherverbrauch ist bei OS 132Byte Flash und 4Byte RAM
Speicherverbrauch ist bei O2 138Byte Flash und 4Byte RAM

Somit wird hier für 6Byte weniger Flashverbrauch Faktor 4,5 bei der 
Geschwindigkeit in Kauf genommen!? Krass

[Ingo L. (corrtexx)]

Daraus schliesse ich, dass wenn es nicht unbedingt auf ein paar Byte 
ankommt man doch lieber O2 nutzen sollte entgegen dem Artikel hier?
AVR-GCC-Codeoptimierung

[Peter II (Gast)]

Ingo Less schrieb:
> Daraus schliesse ich, dass wenn es nicht unbedingt auf ein paar Byte
> ankommt man doch lieber O2 nutzen sollte entgegen dem Artikel hier?

dann kann schon wieder anders aussehen, wenn du mehrfach eine 
Multiplikation im code hast.

[Yalu X. (yalu) (Moderator)]

Ingo Less schrieb:
> Somit wird hier für 6Byte weniger Flashverbrauch Faktor 4,5 bei der
> Geschwindigkeit in Kauf genommen!? Krass

In dem Code, den der Compiler hier sieht, beträgt der Unterschied nicht
6, sondern 20 Bytes, und das ist schon ein deutlicher Unterschied. Der
Platzbedarf für die Bibliotheksroutine dürfte schon bei zwei
Multiplikationen dieser Art mehr als kompensiert werden.

[SF6 (Gast)]

Ingo Less schrieb:
> Somit wird hier für 6Byte weniger Flashverbrauch Faktor 4,5 bei der
> Geschwindigkeit in Kauf genommen!?
Wenn du dem Compiler mit -Os sagst dass er es möglichst klein machen 
soll, dann tut er das auch. Wenn dir das Ergebnis nicht gefällt, dann 
kannst du auch eine andere Optimierung wählen.

[Karl H. (kbuchegg)]

Ingo Less schrieb:

> Somit wird hier für 6Byte weniger Flashverbrauch Faktor 4,5 bei der
> Geschwindigkeit in Kauf genommen!? Krass

Aber nur dann, wenn dein Programm ausschliesslich aus 16*16 Bit 
Multiplikationen besteht.

[Loocee L. (loocee)]

Leicht off topic .....

.... aber ich finde es sehr interessant wieviele Comilerbauer es
hier im Forum gibt:

Ingo Less schrieb:
> Frage an die Compilerbauer

Da muss es ja vor (erschaffenen) Compilern nur so wimmeln (wenn
jeder so im Background seine(n) Compiler baut), bzw. hier gibt es
soviel Optimierungspotential dass ja ein ganz toller optimierter
GCC für die AVRs dabei herauskommen muss.....   (   ;-)   )

[Ingo L. (corrtexx)]

Eberhard F. schrieb:
> Leicht off topic .....
Nein, leicht überflüssig ..... (   ;-)   )

[(prx) A. K. (prx)]

Eberhard F. schrieb:
> .... aber ich finde es sehr interessant wieviele Comilerbauer es
> hier im Forum gibt:

Ist nicht die erste Frage im Forum, die falsch gestellt war. Und wird 
auch nicht die letzte bleiben. Soll sie deshalb verhungern, weil sich 
niemand zu antworten traut?

PS: Ex-Compilerbauer, falls dich das beruhigt. ;-)

[Rolf Magnus (Gast)]

Ingo Less schrieb:
> Somit wird hier für 6Byte weniger Flashverbrauch Faktor 4,5 bei der
> Geschwindigkeit in Kauf genommen!? Krass

Ich würde das Programm nicht mit -Os übersetzen, denn welcher AVR hat 
schon weniger als 138 Bytes Flash? Wie, das ist gar nicht das 
"eigentliche" Programm?
Wie so oft wird hier der Fehler gemacht, von einem Trivialprogramm auf 
den Allgemeinfall zu schließen.
Bei größere Programmen ist die Wahrscheinlichkeit nicht so gering, daß 
die Multiplikationsroutine noch öfter gebraucht wird. Sie ist dann nur 
einmal da mit -Os und muss nur aufgerufen werden. Bei -O2 nutzt der 
Compiler dagegen hier eine optimierte Version, da mit einer Konstanten 
multipliziert wird. Die braucht zusätzlichen Code. Da in diesem 
trivialen Programm sonst keinerlei Multiplikation vorkommt, kann die 
Funktion __mulhi3 dafür weggelassen werden. Erst dadurch fällt der 
Unterschied beim Speicherverbrauch so gering aus.

[Linksammler (Gast)]

Nur der Vollständigkeit halber:

Wenn man das Konsturierte Beispiel etwas realitätsnäher gestaltet, und 
vor allem den Optimizer seine Arbeit machen lässt, dann kommt ein viel 
besseres Resultat heraus.

(Also: Kein Volatile wo's nicht nötig ist. Keine "asm volatile", die 
"zeilen-übergreifende" optimierunen verhindert.)

Also:

#include <avr/io.h>

uint16_t Temp;
volatile uint16_t Temp2;

int main(void)
{
   Temp=0;
    while(1)
    {
      Temp++;
      Temp2 = Temp * 60;
    }
}

wird zu:

.L2:
        adiw r24,60
        sts Temp2+1,r25
        sts Temp2,r24
        rjmp .L2

Moral aus der Geschichte: Dem Kompiler keine Knüppel zwischen die Beine 
werfen, dann klappts auch mit der Optimierung.

[Ingo L. (corrtexx)]

OK,

der eigentlich sinn hintet diesem Banalprogramm war eigentlich, 
herauszufinden ob der Optimizer aus *60 auf einem AVR ohne 
Multiplikationseinheit einen Shift macht.

Nämlich führt Temp2 = Temp * 60 zum selben Ergebnis wie Temp2 = Temp<<6 
- Temp<<2. Die Frage war ob er das selber herausfinden würde. 
Offensichtlich jedoch nicht.

EDIT: Gut, damit hätte ich auch früher rausrücken müssen...

[Jonas B. (jibi)]

ich würde wette aus *64 hätte er ein Lösung mit einem Shift gebaut ;)

Gruß J

[Ingo L. (corrtexx)]

Jonas Biensack schrieb:
> ich würde wette aus *64 hätte er ein Lösung mit einem Shift gebaut ;)
Bei O2 ja, bei Os nein

[Yalu X. (yalu) (Moderator)]

Ingo Less schrieb:
> Nämlich führt Temp2 = Temp * 60 zum selben Ergebnis wie Temp2 = Temp<<6
> - Temp<<2. Die Frage war ob er das selber herausfinden würde.
> Offensichtlich jedoch nicht.

Er macht das sogar noch besser: Nämlich mit

uint16_t Temp3 = Temp;
Temp2 = ((Temp3 << 4) - Temp3) << 2;

Das liegt dem barrel-shifter-losen AVR sehr viel besser. Beachte
außerdem, auf welch geniale Weise der Shift um 4 realisiert ist.

Edit:

Habe noch einen Klammerfehler und eine kleine Unstimmigkeit korrigiert.

[Peter II (Gast)]

Jonas Biensack schrieb:
> ich würde wette aus *64 hätte er ein Lösung mit einem Shift gebaut ;)

dann mach doch einfach

  Temp2 = (Temp * 64) - (Temp * 4);

[Linksammler (Gast)]

Peter II schrieb:
> dann mach doch einfach
>   Temp2 = (Temp * 64) - (Temp * 4);

Warum? Um den Compiler zu schlechterem Code zu zwingen?

Wie Yalu geschrieben hat:
der gcc macht das von selbst sogar noch besser, als sich corrtexx das 
für Hand-Optimierten Code ausgedacht hat.

Lasst den Compiler doch einfach seine Arbeit machen. Der kann das schon.

Hand-Optimieren kann man später immer noch, wenn's denn wirklich nötig 
ist.

[Stefan F. (Gast)]

In meinen Projekten ist das Resultat bei Os und O2 sowohl was 
Performance angeht als auch Speicherbedarf nur wenig Unterschiedlich. 
Ich denke, du hast da durch den abgespeckten Minimal-Code einen 
Extremfall erwischt.

Os würde ich nur im Notfall einsetzen, wenn es wirklich sein muss.

Normal nehme ich O2. Einmal musste ich bei einer bestimmten Version des 
Atmel Compilers auf O1 gehen, ich vermute da einen Bug, weil eben nur 
diese eine Version betroffen war.

O0 nehme ich, wenn ich debuggen möchte.

[Ingo L. (corrtexx)]

Bisher habe ich ich immer OS genutzt, wie es empfohlen wird. hatte 
bisher auch nie das Bedürfnis etwas von Hand zu optimieren. Wie gesagt, 
hier war nur der Versuch was der Optimizer aus dem *60 macht. Aber er 
macht es ja scheinbar noch besser wie erwartet, auch wenn ich den 
Assemblercode mangels Assemblerkenntnissen nicht so recht nachvollziehen 
kann.

[Yalu X. (yalu) (Moderator)]

Meiner Erfahrung nach spart man bei Programmen aus der realen Welt mit
-Os prozentual deutlich mehr Flash-Bytes als mit -O2 Zyklen. Da ich
zudem häufiger Flash-Kapazitäts- als Laufzeitprobleme habe, verwende ich
normalerweise -Os.

[Johann L. (gjlayde)]

Peter II schrieb:
> dann mach doch einfach
>
>

Temp2 = (Temp * 64) - (Temp * 4);

Und was soll da anders sein als mit * 60 ???

*60 in shifts etc. zu expandieren ist nur günstig, wenn es keine MUL 
Befehle gibt.

MUL mit 60 ist dann besser als Rumgeschiebe.

[SF6 (Gast)]

Denkst du nicht, der Compiler hätte den MUL Befehl eingebaut wenn es 
einen gäbe? Beitrag "Re: Frage an die Compilerbauer"

[Johann L. (gjlayde)]

Das weiß die Kristallkugel.

Es ist weder Die Compilerversion genannt noch für welches Device 
übersetzt wurde.

Und ja, avr-gcc macht nicht immer den besten denkbaren Code, und das 
gilt auch für den Code, den er für Multiplikationen erzeugt — auch mit 
avr-gcc 4.9 oder 5.

[Rolf M. (rmagnus)]

SF6 schrieb:
> Denkst du nicht, der Compiler hätte den MUL Befehl eingebaut wenn es
> einen gäbe? Beitrag "Re: Frage an die Compilerbauer"

Der Code dort ist vermutlich für einen attiny übersetzt worden. Wenn man 
stattdessen einen atmega auswählt, wird auch MUL verwendet, und zwar 
sowohl bei -Os als auch bei -O2.

        lds r18,Temp
        lds r19,Temp+1
        mul r20,r18
        movw r24,r0
        mul r20,r19
        add r25,r0
        clr __zero_reg__
        sts Temp2+1,r25
        sts Temp2,r24