# g++ vs MSVisual Studio C++: g++ code nur halb so schnell???

## KingCrimson

Hallo,

ich bin neu hier! Gentoo nutze ich seit kurzem und bin begeistert, ganz ehrlich. Ich komme von SuSE, was ich nicht schlecht finde, dennoch will ich näher dran sein. Soviel vorweg.

ICH BIN KEIN IT-PROFI, eher einer der Dinge tut von denen er noch zu wenig Ahnung hat um sie tun zu dürfen.

Wir haben hier viel unter MS VisualStudioC++.NET 1.1 selbstgeschriebene Software auf Windows XP prof SP2 am laufen. Ich habe ein Linux-Rechen-Grid unter SuSE 9.3 mit pvm aufgesetzt, und es wurden die rechenaufwedigen Teile auf Linux portiert, für den pvm-Grid (1 Server, 12 Rechenknechte). Wobei in dieser Anwendung (noch) nicht parallel gerechnet wird, sondern immer nur das gleiche Programm mit verschiedenem Input an die Rechenknechte verschickt wird.

Problem: auf den Linux Maschinen läuft der g++ code nur halb so schnell wie der MSVS code unter XP. Ich habe eine Maschine mit Linux (SuSE und Gentoo) und Windows aufgestzt, um direkt vergleichen zu können, es bleibt dabei. Laufzeit des Beispielprogrammes (min:sec):

 -XP: 15:02

 -SuSE: 29:20

- Gentoo:22:05

Compiliert man mit dem Intel Compiler, sieht es nicht viel besser aus.

-Compiler:

gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)

icc (ICC) 9.0 20051201

Der Beispielrechner ist eine hp xw6000 Intel Pentium4 Xeon Doppelprozessormaschine (wie der Rest des Grids auch ...). Die benutzten g++ flags waren

```

 make CXXFLAGS=''-O3 -march=pentium4 -ffast-math -msse2 -funroll-loops'' programmname

```

habe auch und und und ...probiert, reißt es aber alles nicht so recht raus.

Fragen: Ist der MSVS compiler tatsächlich besser? Bin ich zu blöd? Kann es an der Betriegssystemkonfiguration (anderen Kernel compilieren) liegen? Soll ich Hyperthreading im BIOS an oder abstellen, und muss dann der Kernel angepasst werden? Warum ist Gentoo etwas schneller als SuSE?

Ich liebe Linux und mag Win gar nicht, drum trifft mich das so hart. Wenn jemand eine oder mehrere der obigen Fragen beantworten kann würde er mir sehr helfen. Ich vermute immer noch, daß ich zu blöd bin, bisher wars fast immer so, und hoffe recht zu behalten, Linux und dem Grid zuliebe, sonst kauft mein Chef noch Win-Lizenzen. Nichts wäre mir peinlicher  :Embarassed: 

Gruss, KC.

----------

## misterjack

 *Quote:*   

> make CXXFLAGS=''-O3 -march=pentium4 -ffast-math -msse2 -funroll-loops'' programmname

 

mal -Os statt -O3 probiert? von den restlichen optionen hat man auch nichts unbedingt gutes gehört, funroll-loops zum beispiel lässt ja den code anschwillen

----------

## KingCrimson

Danke für den Hinweis, hab 's probiert, der code ist zwar nur halb so groß, aber dafür langsamer als "-O3", ist eher in der Größenordnung von "-O0". Schade.

----------

## Anarcho

Vielleicht liegt es aber auch am Code selber. Du hast ja gesagt er wurde portiert. 

Gab es dabei probleme oder musstet ihr nur einen kleinen Teil portieren?

Dazu kommt das g++ noch nicht ganz so toll sein soll wie der C-Compiler vom gcc (habe ich gehört).

Das soll sich wohl mit gcc 4.x geändert haben. Eventuell könntest du mal nen gcc-4.x probieren.

EDIT: Ach ja, was für Operationen führt das Programm aus? Ist es eher Plattenintensiv oder nur Integerzahlen/Realzahlen?

----------

## _hephaistos_

jo, mich würd auch interessieren, wie das mit gcc-4.1.X ausschaut und wie der code so aufgebaut is...

@Anarcho: g++ is der c++ compiler von der gcc (gnu compiler collection). cc is der c compiler

cheers

----------

## franzf

Halb so schnell...

Habt ihr da nur Multi-Prozessor-Rechner rumstehen?

Ist der Code darauf ausgelegt?

Hast du dann den Linux-Kernel mit Unterstützung für Multiple prozessors übersetzt?

(-> Prozessor type an features im menuconfig)

Wenn nicht wäre es eine Erklärung...

----------

## schachti

Die große Frage ist: Was macht das Programm? Welche Bibliotheken werden benutzt? Evtl. liegt dort die Ursache...

----------

## hoschi

Oder kurz gesagt: Das Programm sollte erstmal unter der GPL erscheinen...  :Wink: 

----------

## _hephaistos_

danke hoshi für deinen beitrag...   :Rolling Eyes: 

----------

## Anarcho

 *_hephaistos_ wrote:*   

> jo, mich würd auch interessieren, wie das mit gcc-4.1.X ausschaut und wie der code so aufgebaut is...
> 
> @Anarcho: g++ is der c++ compiler von der gcc (gnu compiler collection). cc is der c compiler
> 
> cheers

 

Und was habe ich gesagt, bitte?

----------

## _hephaistos_

omg sorry  :Wink: 

net gscheid gelesen...

----------

## Ampheus

Es wäre auf jeden Fall einen Versuch wert, SMP im Kernel zu aktivieren. Findet sich unter "Processor type and features".

----------

## platinumviper

 *KingCrimson wrote:*   

> Kann es an der Betriegssystemkonfiguration (anderen Kernel compilieren) liegen? Soll ich Hyperthreading im BIOS an oder abstellen, und muss dann der Kernel angepasst werden?

 

Sieht so aus, als ob Du SMP im Kernel nicht aktiviert hättest, Was kommt denn bei "cat /proc/cpuinfo" raus? Bei aktiviertem Hyperthreading sollten vier, ohne HT zwei CPUs angezeigt werden. Meistens ist es sinnvoll HT einzuschalten, immer wenn ein Thread auf eine I/O Operation wartet, langweilt sich nur eine virtuelle CPU, die zweite kann weiter arbeiten. Für HT solltest Du im Kernel zusätzlich die Option SMT einschalten, SMP reicht zwar prinzipiell auch, aber mit SMT wird noch einmal optimiert.

 *KingCrimson wrote:*   

>  Warum ist Gentoo etwas schneller als SuSE?

 

Weil Du Dein System auf Pentium 4 optimiert hast, SuSE muss aber auch auf älteren Prozessoren laufen, das schränkt die Optimierungsmölichkeiten natürlich stark ein. Außerdem sind unterschiedliche GCC Versionen installiert.

Die Compiler liefern sich ein ständiges Kopf-an-Kopf Rennen, Du hast mit Sicherheit etwas falsch konfiguriert. Da Du die "Rechenknechte" für ihre Aufgabe optimieren kannst, solltest Du bessere Ergebnisse erziehlen als unter Windows. Schmeiß alles aus dem Kernel was Du nicht brauchst, USB, SATA, IDE, Parallelport ... sind überflüssig.

platinumviper

----------

## misterjack

 *platinumviper wrote:*   

>  *KingCrimson wrote:*   Kann es an der Betriegssystemkonfiguration (anderen Kernel compilieren) liegen? Soll ich Hyperthreading im BIOS an oder abstellen, und muss dann der Kernel angepasst werden? 
> 
> Sieht so aus, als ob Du SMP im Kernel nicht aktiviert hättest, Was kommt denn bei "cat /proc/cpuinfo" raus? Bei aktiviertem Hyperthreading sollten vier, ohne HT zwei CPUs angezeigt werden. Meistens ist es sinnvoll HT einzuschalten, immer wenn ein Thread auf eine I/O Operation wartet, langweilt sich nur eine virtuelle CPU, die zweite kann weiter arbeiten. Für HT solltest Du im Kernel zusätzlich die Option SMT einschalten, SMP reicht zwar prinzipiell auch, aber mit SMT wird noch einmal optimiert.

 

Um das ganze voll aus zu nutzen sollte glibc mit USE="ntpl ntplonly" kompiliert sein

----------

## KingCrimson

Erstmal vielen Dank

für die zahlreichen Antworten. Ich beginne nun mit der Aufarbeitung.

Antworten meinerseits:

+ Hyperthreading ist BIOS-seitig an.

+ viel war nicht zu portieren, eher kleinere Änderungen.

+ es wird fast aussschließlich gerechnet, nur am Anfang etwas von Platte gezogen (approx. 1s) und am Ende was kleines geschrieben.

+ GPL: code posten geht nicht, ich habe eine Familie zu ernähren.

+ SMP und SMT sind aktiviert. Ich sehe vier cpus.

Gruß KC.

----------

## schachti

 *misterjack wrote:*   

> 
> 
> Um das ganze voll aus zu nutzen sollte glibc mit USE="ntpl ntplonly" kompiliert sein
> 
> 

 

Du meinst nptl (Native POSIX Thread Library).   :Wink: 

nptlonly braucht man nicht unbedingt, das kann sogar zu Problemen mit einigen Programmen führen.

Und da KingCrimson schreibt, daß vor allem gerechnet wird, wird das im konkreten Fall sicher nicht viel bringen (ebensowenig wie Hyperthreading).

Ich würde mal probieren, in BIOS und Kernel SMP zu aktivieren, Hyperthreading aber zu deaktivieren.

----------

## KingCrimson

@schachti:

Es scheint als hättest Du den Nagel auf den Kopf getroffen.

Der Chef hat an den genutzten libs gedreht und siehe da, alles wird besser. Es liegt wohl daran, daß Zeit/Datums und Kalenderroutinen aufgerufen werden und die Linux lib da wohl sehr viel langsamer ist als die unter win oder einfach ungünstig oft aufgerufen wird. Da wurde jetzt ein wenig nachgebessert und schon sind wir bei Laufzeiten von 21 min (Linux) zu 15 min (win) angekommen. Damit sind SuSE und Gentoo etwa gleichauf, Gentoo immer noch etwas besser, ich bastle noch an alternativem SuSE-Kernel. Langfristig will ich ohnehin auf schmale schnelle Gentoo-Systeme wechseln.

Gruss KC.

----------

## misterjack

 *schachti wrote:*   

> nptlonly braucht man nicht unbedingt, das kann sogar zu Problemen mit einigen Programmen führen.

 

halte ich für ein gerücht. jedenfalls habe ich auf zwei x86er und amd64er damit fahren. keine probs, die ich auf dieses useflag rückgeführt habe

----------

## schachti

Ich hatte das mal mit einem Paket, das sich partout nicht installieren ließ. Erst, als ich die glibc nur mit nptl und ohne nptlonly neu kompiliert hatte, ging es. Ist inzwischen aber schon einige Monate her. Und da der einzige Nachteil, die glibc ohne nptlonly zu kompilieren, darin besteht, daß die glibc zwei Mal gebaut wird und das kompilieren daher doppelt so lange dauert, ist das doch ok...

----------

