• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

CFLAGS der FreeBSD-Packages

franco98

NetBSDler aus Leidenschaft
Themenstarter #1
Hallo FreeBSD-User,

gibt es eine Möglichkeit heraus zu finden, welche CFLAGS die Jungs von FreeBSD beim Bau der jeweiligen Packages der entsprechenden Plattformen benutzt haben?

Also für i386, amd64, sparc, ia64, ...

Mir geht es nicht direkt um den Optimierungs-Flag -O oder -O2, sondern eher um -march oder -mcpu oder -mtune.

Die Pakete sollten ja immer auf den kleinsten möglichen Nenner einer Plattform gebaut sein, der interessiert mich.

Hintergrund ist ein Vergleich von CFLAGS und deren Auswirkung auf die Leistung / Qualität der jeweiligen Programme, also Stabilität, Speichergröße, Geschwindigkeit usw.

Die gesetzten CFLAGS von den FreeBSD-Ports sollen als Vergleich dienen.
Als FreeBSD-Release dient das aktuelle 8.1.

Vielen Dank
Frank aus LE
 

Kamikaze

Warrior of Sunlight
#4
make -VCFLAGS

...

Pointyhat baut mit Standard-CFLAGS, und setzt auch nicht CPUTYPE (woraus sond -march generiert wird).
 

franco98

NetBSDler aus Leidenschaft
Themenstarter #5
make -VCFLAGS

...

Pointyhat baut mit Standard-CFLAGS, und setzt auch nicht CPUTYPE (woraus sond -march generiert wird).
@Kamikaze

Danke! Wie bekomme ich dann raus, für welche min. CPU in der jeweiligen Plattform die Pakete gebaut sind. Ich nehme mal an, das unter i386 kein Programm mehr für den 386er oder 486er gebaut wird. Ich entsinne mich, dass Debian früher in seinen Paketen das Kürzel für die min. CPU in den Paketnamen mit drin hatte. Z.B. programm-1.0-xyz-i586.deb. Das ist bei den FreeBSD-Packages nicht so leicht zu ermitteln.

VG
Frank
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#6
FreeBSD baut die Pakete für FreeBSD/i386 meines Wissens für den i486. Das ist die älteste CPU-Generation, die FreeBSD derzeit unterstützt.
 

franco98

NetBSDler aus Leidenschaft
Themenstarter #7
@Yamagi
Danke! Nun fehlt mir noch der Vergleich für mind. 2 Plattformen, a.B. amd64 und sparc64.
i486 ist aber schon etwas betagt! Unabhängig von meiner Frage und meinem Vorhaben, lohnt sich da noch das Benutzen der packages oder sollte man immer die ports nutzen und optimieren?

VG
Frank
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#8
Zu FreeBSD/amd64: Es gibt dort draußen nur eine einzige amd64-Generation und das ist "HAMMER". Alle CPUs nutzen deren Instruktionen, Erweiterungen gab es seitdem nur im Bereich SSE und nun neu AVX. FreeBSD baut dort gegen den CPU-Typ "k8", was als erste amd64-CPU der kleinste Nenner ist. Ein anderer CPU-Typ bringt dir effektiv aber nur neuere SSE-Versionen und ist damit ohne Anpassungen im Code selbst weitgehend sinnlos.

Überhaupt - das ist Frage 2 - sind bei fast allen Programmen inzwischen irgendwelche Optimierungen durch den Compiler sinnlos. Moderne Prozessoren haben eine so ausgefeilte Codeaufbereitung, dass sie evtl. suboptimalen Code ausgleichen können. Ausnahmen sind Programme, die wirklich intensiv rechnen. Filmencoder, irgendwelche Mathetools, etc. Wenn du über den Compiler mehr als 1 bis 2 Prozent Mehrleistung im Schnitt herausholen willst, musst du einen Compiler deines CPU-Herstellers nutzen, der dann brutal auf deren Prozessoren optimiert und andere benachteiligt. Bei Intel ist es der ICC, bei AMD der Open64. Beide sind aber unter FreeBSD faktisch nicht nutzbar.
 

franco98

NetBSDler aus Leidenschaft
Themenstarter #9
Danke Yamagi!

Es geht mir nicht um die Leistung auf meinem PC direkt, ich möchte vielmehr an Hand einer Gegenüberstellung der jeweiligen Binaries Vergleiche ziehen. Ich habe vor einigen Jahren einen Artikel zur SSL-Verschlüsslung und 32 vs 64 Bit Code gelesen, dies möchte ich nun an Hand von 3 Plattformen und einige ausgewählte Programme wiederholen.

Das Grundsystem ist immer ein FreeBSD-8.1, Standard-Installation. Die Testrechner sind ein PC mit Athlon-XP für i386, ein Notebook mit Dual-Core2 für amd64 (i386 auch mgl.) und eine Blade 1000 für sparc64.

Der Test in einer VM ist nicht möglich, er verfälscht das Ergebnis und die Sparc-Virtualisierung scheint fraglich.

VG
Frank
 

-Nuke-

Well-Known Member
#10
Ich weiß jetzt nicht, ob die Compiler das machen, aber wäre es nicht möglich mit mcpu oder march oder was auch immer z.B. auf einem Intel Atom deutliche Mehrleistung zu kriegen, da der Compiler die Befehle entsprechend der In-Order Architektur des Atoms vorsortieren kann?

Weil der Atom kann ja auf Hardwareebene ja mal so gut wie nix.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#11
Jepp, der Atom ist ein Sonderfall. Seine überholte in-order Architektur ist auch einer der Gründe, dass ich von Teil immer abrate. Mal schauen, wie Intel auf die Bobcat-Architektur von AMD reagieren wird...

Bei Atom könnte dir eine Compileroptimierung auch beim GCC einiges bringen. Das Problem ist dabei aber, dass der GCC 4.2 in der Base doch recht alt ist und den Atom nicht kennt. Es gibt da auch nichts, was nahe kommt, da der Atom - obskure Verwandtschaften mal außen vor gelassen - im Intel-Portfolio allein steht. Man müsste also einen GCC aus den Ports nehmen und den zum Systemcompiler umfummeln, was wieder böse Nebenwirkungen haben kann.

Leider werden wir wohl noch einige Jahre in dieser Situation bleiben, denn aufgrund der GPL3 kann kein neuerer GCC in das Basissystem importiert werden. FreeBSD 9 wird daher Clang mitbringen, aber er ist erst einmal rein optional und auch wenn es langsam wird erreicht die aktuelle Version noch nicht Geschwindigkeit von mit GCC generierten Binaries.
 

Kamikaze

Warrior of Sunlight
#13
... FreeBSD 9 wird daher Clang mitbringen, aber er ist erst einmal rein optional und auch wenn es langsam wird erreicht die aktuelle Version noch nicht Geschwindigkeit von mit GCC generierten Binaries.
Das ist meiner Erfahrung nach sehr Fallabhängig. Rechenanwendungen laufen in der Regel langsamer, I/O lastige Anwendungen bringen mit Clang aber oft mehr Durchsatz.
 

-Nuke-

Well-Known Member
#14
Ein (fast) komplett CPU-unabhängiges FreeBSD wäre mal interessant. Indem man einfach alles als Bytecode kompiliert und dann alles mit dem JiT-C ausführt... :D

Aber das ist jetzt OT :D
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#15
kamikaze hat gesagt.:
Das ist meiner Erfahrung nach sehr Fallabhängig. Rechenanwendungen laufen in der Regel langsamer, I/O lastige Anwendungen bringen mit Clang aber oft mehr Durchsatz.
Okay, ich habe bisher nur rechenintensive Anwendungen getestet. :)