Performance des GCC

[Bernd (Gast)]

Bei codeproject gab es die Tage einen Artikel zum Performance-Vergleich 
diverser Programmiersprachen.

http://www.codeproject.com/KB/tips/Performances.aspx

Denn Sinn des ganzen Unterfangens bei so einfachen Operationen mal außen 
vor gelassen, würde mich mal interessieren wieso der GCC dort so 
schlecht wegkommt.
Im Vergleich zu den anderen Compilern wird für die Berechnungsschleife 
die 4-fache Zeit benötigt.

Ich habe mir mal die Assembler-Ausgabe des GCC (x86 mingw 3.4.5) der 
Additions-Schleife mit Optimierung -O3 angesehen.
Mangels Verfügbarkeit der anderen Compiler würde ich gerne mal sehen wo 
man da den Faktor 4 herausholen kann.
Es kann natürlich sein dass die anderen Compiler die Sinnlosigkeit der 
Schleifen erkennen und diese komplett wegoptimieren.

Hier der Assemblercode von der Additionsschleife (im IDA 
Assembler-Stil):

C

for (j = 0; j < 10000; j++) {
  for (i = 0; i < 100000; i++) {
        C[i] = A[i] + B[i];
    }
}

ASM

xor     edx, edx
loc_401317:
xor     ebx, ebx
lea     esi, [esi+0]
loc_401320:
mov     eax, [ebp+ebx*4+var_A]
mov     ecx, [ebp+ebx*4+var_B]
add     eax, ecx
mov     [ebp+ebx*4+var_C], eax
inc     ebx
cmp     ebx, 1869Fh
jle     short loc_401320
inc     edx
cmp     edx, 270Fh
jle     short loc_401317

[Bartli (Gast)]

> x86 mingw 3.4.5

Na da hast du ja einen ganz aktuellen gcc...

[Bernd (Gast)]

Bartli schrieb:
>> x86 mingw 3.4.5
>
> Na da hast du ja einen ganz aktuellen gcc...

Liegt daran dass der in Zusammenhang mit wxDevC++ auf meinen Rechner 
gekommen ist, und die sind ja immer 'etwas' hintendran.
Ob eine neuere Version bei so einem simpel-Beispiel aber so viel anders 
machen kann?

[Roland H. (batchman)]

Bernd schrieb:
> GCC (x86 mingw 3.4.5)

Wo rennen denn noch solche Zombies rum :-) ?

Also da gibt es dramatische Veränderungen, oft zum Guten, für AVR auch 
mal etwas kontraproduktiv.

Es gibt hier einige, die die gcc-Versionen sammeln bzw. parallel 
vorhalten, um eben die Veränderungen sehen/erkennen zu können.

Hol' Dir doch einfach den aktuellsten und poste mal das Resultat.

[Bernd (Gast)]

Ok, hab mir mal einen neuen GCC installiert, Version 4.6.1 ebenfalls mit 
-O3 und -ansi übersetzt.

C-Programm:

int main ()
{
  volatile int A[100000];
  volatile int B[100000];
  volatile int C[100000];
  int i, j;
  
  for (i = 0; i < 100000; i++) {
    A[i] = rand() + 1;
    B[i] = rand() + 1;
  }
  
  for (j = 0; j < 10000; j++) {
    for (i = 0; i < 100000; i++) {
          C[i] = A[i] + B[i];
      }
  }
  return 0;
}

Ohne volatile schmeißt der GCC 4.6.1 die zweite Schleife komplett raus. 
Die erste bleibt aber kurioserweise erhalten.

Der Assemblercode der zweiten Schleife:

mov     ebx, 2710h
loc_401BDC:
xor     eax, eax
db      66h
nop
loc_401BE0:
mov     ecx, [esp+eax*4+4+var_A]
mov     edx, [esp+eax*4+4+var_B]
add     edx, ecx
mov     [esp+eax*4+4+var_C], edx
inc     eax
cmp     eax, 186A0h
jnz     short loc_401BE0
dec     ebx
jnz     short loc_401BDC

Bis auf dass die Schleife andersherum durchlaufen wird, scheint es von 
den Befehlen her nicht unbedingt schneller zu sein.

Entweder die Intel-Compiler haben da eine geheime Magie, oder mit dem 
Test bei codeproject stimmt gewaltig was nicht.

[Rolf M. (rmagnus)]

Bernd schrieb:
> Ohne volatile schmeißt der GCC 4.6.1 die zweite Schleife komplett raus.

Weil du die dynamischen Arrays durch lokale ersetzt hast.

> Die erste bleibt aber kurioserweise erhalten.

Weil darin rand() aufgerufen wird, und der Aufruf kann nicht 
wegoptimiert werden.

Schleifen wie die sind für SIMD-Instruktionen perfekt. Möglicherweise 
nutzt der Intel-Compiler die. Wenn man dem gcc z.B. noch -march=core2 
angibt, sieht der Code ganz anders aus.

[Bernd (Gast)]

Rolf Magnus schrieb:
> Schleifen wie die sind für SIMD-Instruktionen perfekt. Möglicherweise
> nutzt der Intel-Compiler die. Wenn man dem gcc z.B. noch -march=core2
> angibt, sieht der Code ganz anders aus.

Hh, gibt bei mir momentan noch keinen großen Unterschied.
test mit -O3 -march=core2 -mtune=core2:

mov     ebx, 2710h
lea     esi, [esi+0]
loc_401BF0:
xor     eax, eax
loc_401BF2:
mov     ecx, [esp+eax*4+4+var_A]
mov     edx, [esp+eax*4+4+var_B]
add     edx, ecx
mov     [esp+eax*4+4+var_C], edx
add     eax, 1
cmp     eax, 186A0h
jnz     short loc_401BF2
sub     ebx, 1
jnz     short loc_401BF0

Ich habe den GCC jedoch in einer VM installiert, da ist der core2 ja 
nicht der native Prozessor. Aber wenn ich es explizit angebe sollte er 
es doch für diesen Prozessortyp optimieren können, oder?

Kann man denn davon ausgehen, dass die Laufzeitumgebungen der anderen 
Sprachen (C#, Java) automatisch auf den jeweiligen Prozessor optimieren? 
Das könnte dann ja wirklich ein Pluspunkt für diese Sprachen sein, da 
man bei den compilierenden Sprachen schon bei der Erstellung auf den 
jeweiligen Prozessor optimieren muss.

[Rolf M. (rmagnus)]

Bernd schrieb:
> Hh, gibt bei mir momentan noch keinen großen Unterschied.
> test mit -O3 -march=core2 -mtune=core2:
> mov     ebx, 2710h
> lea     esi, [esi+0]
> loc_401BF0:
> xor     eax, eax
> loc_401BF2:
> mov     ecx, [esp+eax*4+4+var_A]
> mov     edx, [esp+eax*4+4+var_B]
> add     edx, ecx
> mov     [esp+eax*4+4+var_C], edx
> add     eax, 1
> cmp     eax, 186A0h
> jnz     short loc_401BF2
> sub     ebx, 1
> jnz     short loc_401BF0

Hmm, also mein gcc 4.5.2 macht da folgendes draus:
(AT&T-Syntax, da Linux):

        movl    60(%esp), %eax
        leal    400000(%ebx), %esi
        addl    $16, %eax
        movl    %ebx, 52(%esp)
        movl    %eax, 44(%esp)
        movl    $10000, 56(%esp)
        leal    16(%ebx), %eax
        movl    %edi, 48(%esp)
        movl    %eax, 40(%esp)
        movl    60(%esp), %ebx
        leal    16(%edi), %eax
        movl    %eax, 36(%esp)
        .p2align 4,,10
        .p2align 3
.L3:
        movl    52(%esp), %edi
        cmpl    40(%esp), %ebx
        movl    %edi, 28(%esp)
        seta    60(%esp)
        movl    %ebx, %ecx
        cmpl    %edi, 44(%esp)
        movl    48(%esp), %edx
        setb    %al
        orb     60(%esp), %al
        je      .L11
        cmpl    36(%esp), %ebx
        movl    44(%esp), %edi
        seta    60(%esp)
        cmpl    %edi, %edx
        seta    %al
        orb     60(%esp), %al
        je      .L11
        movl    28(%esp), %eax
        .p2align 4,,10
        .p2align 3
.L12:
        movdqu  (%edx), %xmm1
        movdqu  (%eax), %xmm0
        addl    $16, %edx
        paddd   %xmm1, %xmm0
        addl    $16, %eax
        movdqu  %xmm0, (%ecx)
        addl    $16, %ecx
        cmpl    %esi, %eax
        jne     .L12
        decl    56(%esp)
        jne     .L3
.L7:

Viel Setup-Code, aber die innere Schleife (ab .L12) erledigt sowohl das 
Lesen und Schreiben des Speichers, als auch die Addition mit 
SIMD-Befehlen, die immer vier Werte auf einmal bearbeiten können.

Zum Vergleich nur mit -O3:

        movl    $10000, %ecx
        .p2align 4,,7
        .p2align 3
.L3:
        xorl    %eax, %eax
        .p2align 4,,7
        .p2align 3
.L4:
        movl    (%esi,%eax,4), %edx
        addl    (%ebx,%eax,4), %edx
        movl    %edx, (%edi,%eax,4)
        addl    $1, %eax
        cmpl    $100000, %eax
        jne     .L4
        subl    $1, %ecx
        jne     .L3

> Ich habe den GCC jedoch in einer VM installiert, da ist der core2 ja
> nicht der native Prozessor. Aber wenn ich es explizit angebe sollte er
> es doch für diesen Prozessortyp optimieren können, oder?

Ja. Dem Assembler ist ja erstmal egal, was du selbst für einen Prozessor 
hast.

> Kann man denn davon ausgehen, dass die Laufzeitumgebungen der anderen
> Sprachen (C#, Java) automatisch auf den jeweiligen Prozessor optimieren?

Ich würde es vermuten.

> Das könnte dann ja wirklich ein Pluspunkt für diese Sprachen sein, da
> man bei den compilierenden Sprachen schon bei der Erstellung auf den
> jeweiligen Prozessor optimieren muss.

Deshalb werden z.B. bei Multimedia-Sachen die zeitkritischsten Routinen 
oft in mehreren Versionen mit ins Programm aufgenommen, und es wird dann 
anhand der Prozessor-Kennung und/oder kurzen Performance-Messungen zur 
Programmlaufzeit entschieden, welche verwendet wird.

[Bernd (Gast)]

Interessante Sache. Und ich dachte mit dem gcc hat man beim AVR schon 
genug zu kämpfen.
Mit entsprechenden Compileroptionen habe ich es bei mir aber auch noch 
hinbekommen:
-march=core2 -O3 -ftree-vectorize -ftree-vectorizer-verbose=5 -msse 
-msse2

Mit -ftree-vectorizer-verbose bekommt man auch angezeigt aus welchen 
Gründen er Schleifen nicht optimiert.

Laut der gcc Seite:
http://gcc.gnu.org/projects/tree-ssa/vectorization.html

wird bei -O3 -ftree-vectorize automatisch angewendet. Ich denke bei mir 
fehlte die Option -msse -msse2.

Demnach scheint der GCC also doch gar nicht so schlecht zu sein, man 
muss ihm nur etwas unter die Arme greifen.

[Rolf M. (rmagnus)]

Bernd schrieb:
> Demnach scheint der GCC also doch gar nicht so schlecht zu sein, man
> muss ihm nur etwas unter die Arme greifen.

Naja, er erzeugt halt per Default erstmal Code, der auch auf einem 386er 
noch läuft. Will man mehr, dann muß man es explizit angeben.

Ich finde es allerdings interessant, daß -O3 wohl je nach Betriebssystem 
unterschiedlich arbeitet. Ich habe nur -O3 -march=core2 angegeben und 
sonst nichts. Aber es ist nicht auszuschließen, daß Ubuntu hier an den 
Default-Einstellungen geschraubt hat. Das tun die ja gerne.

[Johann L. (gjlayde)]

Bernd schrieb:
> Ok, hab mir mal einen neuen GCC installiert, Version 4.6.1 ebenfalls mit
> -O3 und -ansi übersetzt.
>
>   volatile int A[100000];
>   volatile int B[100000];
>   volatile int C[100000];

Was ist denn das für ein unsinniger Test?

Man will die Performance von Compiler(Optimierungen) testen, schliesst 
aber via volatile praktisch alle Optimierungen aus.

Merke: Wenn man Benchmarks machen will, sollte man den Code benchmarken, 
für den man sich interessiert und nicht irgendeinen Märchencode.

Wenn man sich zB für die Performance eines AVR-Compilers interessiert, 
ist es ziemlich sinnfrei, für die Bewertung SPEC2000-Benchmarks für den 
Compiler zu machen...

[Bernd (Gast)]

Johann L. schrieb:

> Was ist denn das für ein unsinniger Test?
>
> Man will die Performance von Compiler(Optimierungen) testen, schliesst
> aber via volatile praktisch alle Optimierungen aus.
>
> Merke: Wenn man Benchmarks machen will, sollte man den Code benchmarken,
> für den man sich interessiert und nicht irgendeinen Märchencode.
>
> Wenn man sich zB für die Performance eines AVR-Compilers interessiert,
> ist es ziemlich sinnfrei, für die Bewertung SPEC2000-Benchmarks für den
> Compiler zu machen...

Das mit volatile war ein Test, steht doch auch oben. Denn wenn nach der 
for-Schleife nichts mehr kommt, wird diese wegoptimiert.
Das volatile habe ich bei den späteren Tests wieder entfernt. Die 
wirkliche Optimierung kam aber (zumindest bei dem Windows MinGW GCC) 
erst mit der weiteren Übersetzungsoption -msse2.

Der grundsätzliche fragwürdige "Benchmark" ist auch nicht auf meinem 
Mist gewachsen, siehe codeproject Link im ersten Beitrag. Man müsste 
dort nachfragen was der Autor sich von diesem erhofft hat. Mir ist nur 
aufgefallen dass er den GCC explizit als schlecht darstellt. Und diesen 
nutze ich eben für meine privaten Spielereien ausschließlich - da muss 
man doch mal nachforschen.

[Sven P. (Gast)]

Du müsstest in erster Linie mal verstehen, was passiert.

Natürlich kann man den gcc benchmarken. Es gibt zehnzeilige 
C++-Quelltexte, die mehrere Stunden kompilieren, andere Compiler 
erledigen das vielleicht schneller.

Man kann auch das nackte Kompilat benchmarken. Etwa im Hinblick darauf, 
wie effizient es ist und wie gut der Compiler optimiert hat.

Schließlich lässt sich auch die ganze Toolchain benchmarken, wobei dann 
auch profilorientierte Optimierungen möglich sind.

Man kann auch Äpfel und Birnen miteinander vergleichen, etwa wenn man 
native Compiler mit JIT vergleicht. Der Java-Compiler wird kaum auf 
irgendeinen Prozessor optimieren. Die ganzen .NET-Compiler vermutlich 
auch nicht, das wäre ziemlich sinnfrei wo doch der Sinn von Java und 
.NET ein gewisser Grad an portabilität sein soll. Da ist vielmehr 
interessant, was die Laufzeitumgebung, also etwa die Java-VM, auf der 
jeweiligen Plattform anstellt.


GCC ist mit C++ aber tatsächlich nicht der schnellste, es hilft meist, 
vorkompilierte Header zu benutzen. Dafür hat(te) der GCC aber auch 
längere Zeit den Ruf, quasi perfekten Code zu erzeugen. Sagt(e) man, wer 
weiß, ob was dran ist oder war.

[Uwe (Gast)]

Intel bewirbt diesen Compilere ja  gerade wegen der super Optimierungen 
durch SIMD und Multiprocessing. Schon mal auf der Website von Intel 
geguckt was der so kann ?

[Dussel (Gast)]

>Es gibt zehnzeilige C++-Quelltexte, die mehrere Stunden kompilieren
Standard C++? Hast du da ein Beispiel? Würde mich mal interessieren.

[Peter II (Gast)]

Dussel schrieb:
> Standard C++? Hast du da ein Beispiel? Würde mich mal interessieren.

da eine keine zeilenlänge begrenzung in C gibt, kann das ein kompletten 
openoffice sein.

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

Dussel schrieb:

>>Es gibt zehnzeilige C++-Quelltexte, die mehrere Stunden kompilieren
> Standard C++? Hast du da ein Beispiel? Würde mich mal interessieren.

Wohl 10 Zeilen in einem .cpp File und ein paar "etwas grössere" 
Include-Files mit Stapel über Stapel aus Templates.

[Klaus W. (mfgkw)]

Peter II schrieb:
> Dussel schrieb:
>> Standard C++? Hast du da ein Beispiel? Würde mich mal interessieren.
>
> da eine keine zeilenlänge begrenzung in C gibt, kann das ein kompletten
> openoffice sein.

Aber nicht, wenn du mehr als 9 #include brauchst :-)

[Sven P. (Gast)]

struct a {
  typedef int foo;
};

struct a1: a{
};

struct a2: a{
};

#define X(p,q)        \
  struct q##1: p##1, p##2 {  \
  };        \
  struct q##2: p##1, p##2 {  \
  };

X(a,b) X(b,c) X(c,d) X(d,e) X(e,f) X(f,g) X(g,h) X(h,i) X(i,j) X(j,k) X(k,l) X(l,m) X(m,n)

n1::foo main(){
}

Siehe Fefe sein Blog (http://www.fefe.de/c++/)

[Dussel (Gast)]

Tatsächlich. "Virtual memory exhaustet. Cannot allocate memory"
Ist ja interessant. Danke

[Peter II (Gast)]

dann nehmt einen richtigen compiler

cl test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 
for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.


dauer <1sec und ferig.

[Klaus W. (mfgkw)]

Welche Compileroption hatte der nochmal, um ISO-C99 schreiben zu können?

[Peter II (Gast)]

Klaus Wachtler schrieb:
> Welche Compileroption hatte der nochmal, um ISO-C99 schreiben zu können?

es ging am C++, gab es da überhaupt ISO-C99 wenn ja ist es aber auch 
schon veraltet.

[Klaus W. (mfgkw)]

Bei C++ ist er auch nicht viel neuer (C++11).

[Peter II (Gast)]

Klaus Wachtler schrieb:
> Bei C++ ist er auch nicht viel neuer (C++11)

davon wird aber ein grossteil bereits unterstützt. Ich denke da nehmen 
sich MS und GCC nicht viel.

[Rolf M. (rmagnus)]

Peter II schrieb:
> Klaus Wachtler schrieb:
>> Welche Compileroption hatte der nochmal, um ISO-C99 schreiben zu können?
>
> es ging am C++, gab es da überhaupt ISO-C99 wenn ja ist es aber auch
> schon veraltet.

Es handelt sich bei beiden Compilern um kombinierte C- und C++-Compiler. 
Was C betrifft: C99 ist mittlerweile quasi veraltet, wird aber vom 
Microsoft-Compiler noch immer nicht auch nur ansatzweise unterstützt. 
Microsoft setzt weiter auf C90, das es eigentlich seit 12 Jahren nicht 
mehr gibt.

[Roland H. (batchman)]

> test mit -O3 -march=core2 -mtune=core2:

D. h. mit -mtune wird es noch besser als nur mit -O3 ?

Gilt das auch für -Os ?

Wenn nun -mcpu auf cortex-m3 oder cortex-m4 steht, was würde man dann 
für -mtune wählen?

http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

[Daniel -. (root)]

Rolf Magnus schrieb:
> Hmm, also mein gcc 4.5.2 macht da folgendes draus:
> (AT&T-Syntax, da Linux):

objdump.exe -d main.o -j .text -M intel

mittlerweile habe ich mich an AT&T Syntax gewöhnt^^

[Daniel -. (root)]

vielleicht passend zur Thematik.
ich habe in letzten Tagen auch mit GCC (version 4.5.3) 
herumexperementiert.
Interessant sind die Vergleiche zwischen -O1 und -O2 und ohne 
Optimierung.
Einmal mit konstantem Parameter, einmal mit einem laufzeitabhängigen 
Parameter.

$ cat main.c

#include <stdio.h>
#include <time.h>

int y(int x)__attribute__((const));
int y(int x) {
        return x+1;
}

int yy(int x)__attribute__((pure));
int yy(int x) {
        return x+1;
}

int yyy(int x) {
        //printf("%i", time(NULL));   // make sure it has side-effects
        return x+1;
}

int main() {
        int x1,x2,x3,x4,x5,x6;
        int x;
        scanf("%i", &x);
        x1=y(x);
        x2=y(x);
        x3=yy(x);
        x4=yy(x);
        x5=yyy(x);
        x6=yyy(x);
        // x1=y(1);
        // x2=y(1);
        // x3=yy(1);
        // x4=yy(1);
        // x5=yyy(1);
        // x6=yyy(1);
        printf("%i-%i\n", x1,x2);
        printf("%i-%i\n", x3,x4);
        printf("%i-%i\n", x5,x6);
}