Re: Compileroptimierungen

2008/1/29 Oliver Fromme <olli(at)lurza.secnetix.de>:
>> nighthawk wrote:
>>> Wenn man GCC keine march und keine mtune Parameter mitgibt, wird dann
>>> überhaupt irgendeine Optimierung durchgeführt? Sprich, erkennt GCC den
>>> Prozessor auf dem es läuft und optimiert sein Kompilat explizit für
>>> dieses Modell oder wird per default auf Portabilität zu möglichst
>>> vielen verschiedenen CPU Modellen einer Architektur optimiert?
>
> Die Frage von "nighthawk" war, ob gcc für den betreffenden
> Prozessor optimiert, auf dem er läuft. Die Antwort ist
> nein.

Danke für die klare Aussage.
Ich finde es schade, daß dies nirgends so explizit dokumentiert ist.
Falls es das doch ist, steht es m.E.n. an der falschen Stelle, denn
ich habe lange in der GCC Dokumentation rumgesucht.

> Wenn man für einen bestimmten Prozessor optimieren möchte,
> sollte man eine Zeile "CPUTYPE=..." in /etc/make.conf
> hinzufügen.
>
> Auf meinem Notebook steht da z.B. "CPUTYPE=pentium4m" (ist
> ein Centrino mit Pentium-IV-Mobile), und auf meinem VIA-
> EPIA-Server "CPUTYPE=c3-2" (C3 mit Nehemiah-Core), und auf
> einem Athlon64 "CPUTYPE=athlon64" (wohlgemerkt mit 32bit
> i386 FreeBSD, nicht 64bit).

Ich installiere gerade ein 7.0-PRERELEASE von vor ca. einer Woche.
Dort ist GCC 4.2 der Defaultcompiler. 4.2 unterstützt allerdings keine
explizite Optimierung für Core2duo Prozessoren. Daher habe ich mir GCC
4.3 aus den Ports installiert und über CC, CPP und CXX die 4.3er
Binaries für Portkompilierungen zum Defaultcompiler befördert.
Wenn ich jetzt CPUTYPE=core2 angebe, wird dann der Core2duo
Optimierungsweg für GCC 4.2 gewählt (m.W. ARCH=nocona mit 64Bit, SSE3
usw) oder wird gcc (auf welchem Wege auch immer) -march=core2
mitgegeben? Ich bin aus den mk-Dateien nicht so ganz schlau geworden,
tippe aber eher auf erstgenanntes Verhalten.

> Ob das allerdings viel bringt, darüber wird gestritten.
> In der Praxis dürfte man in den meisten Fällen nicht viel
> davon merken. Ich lasse daher meistens den CPUTYP leer
> (obiges sind die Ausnahmen), damit ich auch problemlos
> Binaries von einem Rechner auf einen anderen kopieren kann.

Da ich nicht die Binaries nicht auf andere Rechner kopieren können
möchte, habe ich mir gedacht, daß ich die vom Compiler angebotenen
Optimierungsmöglichkeiten ruhig nutzen kann. Schaden werden sie
sicherlich nicht. Was ich aber sehrwohl gefunden habe ist die Aussage,
daß die falschen Optimierungen durchaus gegenteilige Ergebnisse
bewirken können. Daher interessiert mich auch welcher Optimierungsweg
hier beschritten wird.

> PS: In -current wurde/wird die Möglichkeit implementiert,
> dass man einfach "CPUTYPE=native" sagen kann, damit man
> sich keinen Kopf machen muss, welche Bezeichnung man da
> genau reinschreiben soll. Es soll ja Leute geben, die
> nicht genau wissen, was sie für einen Prozessor haben.
> Ich weiß leider nicht genau, wie weit das jetzt ist. In
> 6-stable geht es jedenfalls noch nicht.

Current ist derzeit 8.0, oder? In den mk-Dateien von 7.0 habe ich
keinen CPUTYPE "native" entdecken können. Zudem weiß ich ja, daß sich
ein Core2duo in dem Rechner befindet. ;-)
Ich kam auf diese ganze Fragestellung überhaupt, weil ich beim
Kompilieren der Ports bemerkt habe, daß überhaupt kein mtune oder
march angegeben war. Das Nichtangeben von march und mtune in den
C..FLAGS hat den Vorteil, daß auch Ports, die sich nicht an die Werte
in CC, CPP und CXX halten, aber die entsprechenden C..FLAGS sehrwohl
beachten, nicht mit einem Kompilierungsfehler abbrechen, daß die
Architektur "core2" ungültig wäre. Wenn das allerdings nun darin
resultiert, daß dann keine Optimierungen stattfinden, pflege ich
lieber eine Liste mit Ausnahmen - so viele sind das nicht.

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 29 Jan 2008 - 11:50:36 CET