Re: CFLAGS in /etc/make.conf / Optimierungen

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Thu, 27 Dec 2007 13:30:57 +0100 (CET)

Alvar Freude wrote:
> Oliver Fromme wrote:
> > - Man sollte bei den CFLAGS grundsätzlich "?=" statt "="
> > verwenden, damit einzelne Makefiles die Einstellung
> > überschreiben können, wenn es notwendig ist.
>
> OK, verstehe.
>
> Wobei das bei den Ports meines Wissens dennoch klappt, da wohl make.conf
> zuvor eingelesen wird.
> Mein PostgreSQL hat beide Angaben in den Compilerflags, das -O2 kommt von
> /etc/make.conf, das -O3 aus de Ports (das ist eine extra Option).

Ja, es gibt eine Reihe vn Ports, die eine config-Option
»with optimized CFLAGS« o.ä. haben. Wenn man das ein-
schaltet, überschreibt es alles andere.

> pg_config:
> CFLAGS = -O2 -pipe -march=athlon64 -O3 -funroll-loops -Wall [...]
>
> der GCC nimmt da hoffentlich letzteres ;-)

Ich denke schon. Bleibt nur zu hoffen, dass irgendwo auch
noch -fno-strict-aliasing auftaucht (es sei denn, es wurde
geprüft, dass die betreffenden Sourcen Aliasing-clean sind,
aber das ist nicht unbedingt wahrscheinlich).

> > - Es gibt keinen Grund, -O zu verwenden und damit den
> > Code unnötig langsamer zu machen.
>
> Ich bin ja bisher davon ausgegangen, dass *kein* -O (sondern quasi ein
> -O0) verwendet wird. So ist meines Erachtens auch die Dokumentation zu
> interpretieren.

Tatsächlich? Welche Stelle der Doku macht auf Dich diesen
Eindruck? Ich bin noch nie auf die Idee gekommen, das so
zu interpretieren.

> > - Davon abgesehen sind die Default-Compilerflags bereits
> > so eingestellt, dass man das Maximum an Performance
> > erhält, das möglich ist, ohne dass bekannte sich Bugs
> > oder bekannte Probleme manifestieren.
>
> ... was aber so nicht dokumentiert ist!

Stimmt, es wäre besser, wenn das explizit irgendwo stünde.

Aber im Zweifelsfall würde ich eigentlich davon ausgehen,
dass der Default so eingestellt ist wie oben beschrieben.
Grundsätzlich sollte sich ein Rechner ohne make.conf schon
relativ sinnvoll verhalten, d.h. keinen vollkommen unopti-
mierten Code erzeugen. Das ergäbe keinen Sinn. Auch an
anderen Stellen sind ja sinnvolle Defaults zu finden.
Von den zahlreichen /etc/*.conf Dateien kann man ja viele
einfach ignorieren, da die Defaults meistens genügen.

> Gibt es noch weitere Sachen, die in /usr/src/share/examples/etc/make.conf
> quasi empfohlen werden aber nicht eingesetzt werden sollen?

Eigentlich gibt es dort gar keine Empfehlungen, sondern nur
knappe Beschreibungen der einzelnen Variablen.

> > Übrigens, momentan ist der Default sowohl unter RELENG_6
> > als auch RELENG_7 »-O2 -pipe -fno-strict-aliasing«.
>
> wo wird das denn definiert?

/usr/share/mk/sys.mk

> > > Beim Kernel macht u.U. ja alles ab -O2 Probleme,
> >
> > Nö. Die Einstellungen für den Kernel sind aktuell diesel-
> > ben wie für den Rest, jedenfalls unter FreeBSD/i386 und
> > ohne DEBUG (bei amd64 sieht es etwas anders aus), und von
> > einigen speziellen Sourcen abgesehen.
>
> Bei i386 unter 5.x hatte ich mit -O2 mal Probleme, der Compile-Vorgang
> wurde abgebrochen.

Was genau hattest Du in /etc/make.conf stehen? Wie gesagt,
wenn Du "=" statt "?=" verwendet hattest, und/oder wenn Du
die Option -fno-strict-aliasing vergessen hattest, dann ist
das durchaus erklärlich.

> > Kann man übrigens in /sys/conf/kern.pre.mk nachlesen.
>
> ... was aber auch nicht dokumentiert ist,

Das liegt wohl daran, dass erwartet wird, dass Otto-Normal-
user nicht an den COPTFLAGS dreht. Und ein Developer, der
gründe hat, daran zu drehen, weiß, wo er nachgucken muss
(erstens wird es gleich zu Beginn vom Kernel-Makefile
includet, zweitens weist /usr/share/mk/bsd.cpu.mk darauf
hin).

> und dort ist auch nicht
> dokumentiert, warum welche Einstellung gewählt wird. ;-)

Das würde den Rahmen bei weitem sprengen. Allein die Er-
klärung, was es mit Aliasing und der Option -fno-strict-
aliasing auf sich hat, kann ein ganzes Kapitel in einem
Buch füllen und ist für Nichtprogrammierer vermutlich
nicht so ohne weiteres nachvollziehbar. Du kannst ja mal
in der cc(1)-Manpage (oder im gnu-info-File) den Abschnitt
über -fstrict-aliasing durchlesen. Wenn man mit C vertraut
ist, sollte man es verstehen können.

Im allgemeinen wird nur ganz selten dokumentiert, warum
eine bestimmte Einstellung gemacht wird. Es wird erwartet,
dass jemand, der sich dafür interessiert, es anhand der
vorhandenen Dokumentation selbst nachvollziehen kann.
Allerdings werden Änderungen in den Commit-Kommentaren
manchmal begründet, damit andere Developer die Änderung
nachvollziehen können, oder die Begründung ist in einer
vorausgehenden Diskussion in einer der Mailinglisten zu
finden.

> > > Was ist zu CPUTYPE zu sagen?
> >
> > Das ist eigentlich in der make.conf(5)-Manpage hinreichend
> > beschrieben. Wenn Du eine konkrete Frage dazu hast, heraus
> > damit.
>
> Ich wollte damit nur fragen, ob es dagegen auch etwas einzuwenden ist;
> da make.conf(5) ja nicht vollständig ist, kann man sich darauf ja
> offensicht nicht verlassen.

Achso. Also, ich hatte bisher keine Probleme damit. Wenn
man den Wert richtig setzt, sollte das in Ordnung sein.
Wie ich schon in einer anderen Mail schrieb, beeinflusst
der Wert erstens den Assembler-Befehlssatz, den der Compi-
ler ausspuckt (-march Option), und zweitens das Tuning für
den betreffenden Prozessor (-mtune Option). Letzteres
bedeutet in erster Linie, dass der Compiler versucht, die
Maschinenbefehle möglichst so zu verteilen, dass die Tiefe,
Anzahl und Parallelität der Pipelines, über die der betref-
fende Prozessor verfügt, möglichst optimal ausgenutzt wer-
den.

> > Ja, wobei es aber auch kein großer Schaden ist, wenn man es
> > nicht tut. Ich glaube, in den meisten Fällen kann man den
> > Unterschied höchstens messen, aber nicht fühlen.
>
> Das kommt wohl auf den Default-Wert an ... ;-)

Ja, siehe oben. :-)

> > > warum ist das nicht dokumentiert?
> >
> > Das ist eine sehr gute Frage. Ich würde mir wünschen,
> > dass die ganze Sache besser in share/examples/etc/make.conf
> > und in make.conf(5) beschrieben wird, inkl. entsprechenden
> > Warnungen. Ich hatte das vor kurzem mal in der -current-
> > Liste angesprochen, und jemand hat dann den Wortlaut auch
> > ein wenig klarifiziert, aber ich glaube, nach RELENG_6 hat
> > die Änderung ihren Weg leider nicht gefunden.
>
> Es wäre auf jeden Fall gut, wenn das in beiden klar und deutlich steht.
> Denn alles andere kann man ja nicht wirklich erraten.

Ja, ich finde auch, dass eines von beiden überflüssig ist
und entsorgt werden sollte (z.B. die example-Datei), oder
aus dem anderen generiert werden sollte. Es sollte nicht
die gleiche Dokumentation verschiedenen Orten gepflegt
werden, denn sonst besteht immer die Gefahr, dass sie
auseinanderläuft. Die example-Datei ist eh relativ witz-
los, finde ich.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
 > Can the denizens of this group enlighten me about what the
 > advantages of Python are, versus Perl ?
"python" is more likely to pass unharmed through your spelling
checker than "perl".
        -- An unknown poster and Fredrik Lundh
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 27 Dec 2007 - 13:31:09 CET

search this site