FreeBSD make.conf CPUTYPE für CORE i7

reakktor

reakktor

Well-Known Member
Hi zusammen

Beim letzten "buildworld" (csup 12.05.2011, FreeBSD 8-STABLE, 8.2) bin ich über exakt das gleiche Problem gestolpert, wie in
http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023359.html
beschrieben.

Code: 
make-roken.c
make-roken.c:1: error: bad value (core2) for -march= switch
make-roken.c:1: error: bad value (core2) for -mtune= switch
/usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1:
error: bad value (core2) for -march= switch
/usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1:
error: bad value (core2) for -mtune= switch
*** Error code 1
1 error
*** Error code 2
*** Error code 1

Abhilfe schaffte ein CPUTYPE?=native, wie im Thread dort beschrieben.

Ich habe nun länger recherchiert, auch hier, aber die recht widersprüchlichen Informationen, die ich dabei gefunden habe, veranlassen mich doch, da mal nachzuhaken.

Dazu ein paar Fragen:
1. Ist "core2" wirklich obsolet ?
2. Was nimmt man denn für einen Core i7 975?
3. Gibt es irgendwo eine verlässliche(!) Liste für CPU -> make.conf CPUTYPE und Flags ?
4. Auf welchem Versions-Stand ist der FreeBSD-Basis-GCC nun wirklich (4.2 steht zwar drauf, aber ist wohl mehr drin), was versteht der nun und was nicht, grade im Hinblick auf -march=native z.B.?

Ich erinnerer mich an einen Post einer unserer Gurus (yamagi, kamikaze?), der meinte, dass die Runtime-Optimierung der modernen CPUs schon so gut ist, dass dies eh keinen Unterschied macht (kann Thread grad nich finden) - aber dem stimme ich nur bedingt zu.
Auch moderne Prozessoren profitieren immer noch von Vor-Verdauung. Die Optimierung im Prozessor selbst schluckt nun mal auch Rechenzeit, die Pipelines und Caches sind immer noch klein - komplexere Strukturen kann ein Compiler immer noch wesentlich besser abfackeln.

Ich weiss, dass der Base-GCC langsam aus der Steinzeit ist, aber CLANG/LLVM lässt für die Allgemeinheit ja noch auf sich warten. Kleines Dilemma.

Die fundiertesten Infos kamen irgendwie immer aus den Foren hier, hoffe auch diesmal auf ein wenig Erleuchtung ;)
 
Also... Der Basis-GCC in FreeBSD 8.2 und 7.4 ist ein GCC 4.2 mit einigen Patches aus späteren Versionen. Diese fixen vor allem Bugs. Nun wurde er vor einigen Wochen allerdings auf die letzte GPL2-Version aktualisiert, er ist in 7-STABLE, 8-STABLE und 9-CURRENT eine Zwischenversion aus GCC 4.2 und GCC 4.3. Die große Änderung ggü. der alten VErsion ist vor allem eine bessere Unterstützung für AMDs K10-Architektur.

Nun zur eigentlichen Frage. "native" wählt den CPU-Typ aus, den GCC für am geeignetsten hält. Leider ist die Erkennung teilweise etwas merkwürdig, aber im Großen und Ganzen tut es schon. Da der Basis-GCC viel zu alt ist um die Nehalem-Architektur deines Core i7 zu unterstützen, sollte er da "core2" wählen. Das wäre auch nicht weiter schlimm, denn tatsächlich unterscheiden sich die Rechenwerke zwischen "Conroe" Core 2 und "Nehalem" Cire i7 wesentlich weniger, als Intel uns glauben machen wollte. Der deutliche Anstieg an Geschwindigekit resultierte hauptsächlich aus verbesserter Cacheanbindung und dem Ende des auch 2006 schon restlos veraltetem Frontsidebus als enger Flaschenhals.

Der pragmatische Tipp wäre nun, da "native" reinzuschreiben und es dann so zu lassen. Die Code-Aufbereitung des Nehalem ist so gut, dass du in >98% aller Anwendungen eh keinen Unterschied zu einem neuen Compiler sehen würdest. Wenn es dir dennoch wichtig ist, wäre der zu gehende Weg die Basis weiterhin mit dem Basis-GCC zu bauen (alles andere macht einfach zu viel Ärger), für die Ports den Compiler per make.conf auf eine neuere Version wie GCC 4.6 zu überschreiben. Wobei ich nun auch nicht konkret weiß, wie das geht. Wird aber sicher jemand anders sagen können.

EDIT: Ich sehe gerade, dass der Base-GCC "core2" auch noch nicht unterstützt. Also wird er dann wahrscheinlich irgendein Netburst-Derivat wählen, wenn du "native" setzt. Das wäre nicht so gut, da Intels Netburst-Architektur kaum was mit den (entfernt auf P6 basierenden) späteren Modellen gemeinsam hat. In dem Fall wäre es wohl besser den Schalter gar nicht zu nutzen.
 
Erst mal Danke an Yamagi an die Top-Informationen mal wieder. So prima komprimierte/ zusammenfassende Infos, was hinter den Kulissen abgeht, vermisse ich oft.

Dank auch an die BSDforen Wiki Leute, haben mich auf die richtige Spur gebracht:

In der make.conf:

Code: 
# use GCC 4.6 flags on multimedia
.if !empty(.CURDIR:M/usr/ports/multimedia*) && exists(/usr/local/bin/gcc46)
CC=gcc46
CXX=g++46
CPP=cpp46
CPUTYPE=native
CFLAGS+= -Ofast -fno-strict-aliasing -pipe
.endif

Bis jetzt keine Probleme bei port-Builds, das Grundsystem belasse ich lieber mal bei den default-Einstellungen bzw. vergleiche CPUFLAGS?=native/core2 und schaue mal.

ABER: Auch mit gcc4.6 hinkt die FreeBSD-Performance messbar hinter einem Debian6 zurück, zumindest beim Video-Processing mit transcode/ffmpeg.

Hintergrund bei dem allem: Batch-Video-Processing: Bei einem Encoding-Job, der 8 Stunden dauert und mit 12 Rechnern parallel ist jedes Prozent Leistung/Optimierung Gold wert und spart in Summe enorm Zeit/Geld.
Pi*Daumen spart jedes Prozent Leistung im Monat 8 Stunden, was einen zusätzlichen Job/Monat bedeutet, der verarbeitet werden kann.

Mit so einem Mörderteil an Prozessor is man natürlich versucht, das Optimum rauszuholen, deshalb hab ich mal die üblichen Jobs hier mit dem Ding gestest. Muss leider sagen, war unter FreeBSD etwas enttäuscht von der Leistung.
Evaluiere seit längerem Linux <-> FreeBSD in dem Zusammenhang, und muss leider sagen, dass Linux da grade die Nase vorne hat. Längere transcode/ffmpeg-Scripts/Prozesse rennen einige Prozente schneller auf Linux.

Als FreeBSD-Fan versuche grade ein wenig die Ursache zu finden und gegenzusteuern. Den 4.6-gcc für die Ports zu verwenden ist ein erster Schritt, aber ich befürchte Stabilitäts-Proleme....
Tips immer willkommen...
 
Wobei ich mir nicht mehr sicher bin, ob meine Aussage wirklich stimmte. Ich glaube, dass dieser Frankenstein-GCC in -CURRENT und 8-STABLE und "core2" können sollte... Was aber nichts daran ändert, dass er recht überholt ist.
 
core2 Unterstützung wurde erst kürzlich (ich meine erst diesen Monat) in 8-STABLE eingeführt. Da gibt es einen Bootstrapping Bug in Kerberos, den man dadurch bemerkt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben