FreeBSD amd64 - Make.conf Optimierungen nötig?

MorLipf

Member
Hallo,

ich nutze seit gerade eben ein FreeBSD 6.0-rc1 amd64. In der BSD-Wiki habe ich gelesen, dass man CPU-Optimierungen für GCC in die Make.conf eintragen kann. Ist das auch für ein amd64 System nötig oder werden hier alle Athlon64-Flags automatisch gesetzt?

Wenn welche nötig sind, könnt ihr mir erklären, was ich in die make.conf hinzufügen sollte?



MfG
MorLipf
 
Insbesondere interessiert mich, ob alle Funktionen wie SSE und SSE2 des Athlon64 auch ausgenutzt werden, wenn die make.conf keine speziellen CFlags eingetragen bekommen hat.

btw: Wieso ist der KDE 3.4.3 noch nicht in den Ports? Weiß das zufällig jemand?
 
MorLipf schrieb:
Insbesondere interessiert mich, ob alle Funktionen wie SSE und SSE2 des Athlon64 auch ausgenutzt werden, wenn die make.conf keine speziellen CFlags eingetragen bekommen hat.

btw: Wieso ist der KDE 3.4.3 noch nicht in den Ports? Weiß das zufällig jemand?

In der SPARC64 version ist KDE auch noch nicht drinn. Habs mit meiner Ultra AXi selber kompiliert, dauerte ca. 24 stunden, läuft auch, aber trääägend langsam..
 
Soweit ich es verstanden habe nimmt gcc bei x64 Prozessoren automatisch -msse2 und -mfpmath=sse an. Zum bauen von Ports empfehle ich dir

CFLAGS=-O2 -mmmx -msse -msse2 -m3dnow -mfpmath=sse

Falls AMD64 auch sse3 unterstützt (glaube ich aber nicht), natürlich auch -msse3.

Während die Flags für Befehlssatzerweiterung beim bauen von Ports noch nie bei mir Probleme bereitet haben, führen sie beim Bauen der Welt oder des Kernels immer zum Abbruch.

Wenn du die Möglichkeiten der make.conf voll ausnutzen willst: http://wiki.bsdforen.de/index.php/FreeBSD_-_make.conf_optimieren
 
Die neuen Athlon64-Kerne unterstützen alle SSE3, mein etwas älterer Winchester aber noch nicht.

Gibt es auch eine CPUTYPE-Option die ich setzen kann, etwa athlon64? Und was ändert diese Option eigentlich?

Edit: Wird 3dnow auch standardmäßig genutzt?
 
Ich glaube nicht das 3dnow standardmäßig nicht genutzt wird. Welche Optionen für CPUTYPE zur Verfügung stehen kannst du in /usr/share/examples/etc/make.conf nachlesen.
 
[LoN]Kamikaze schrieb:
Während die Flags für Befehlssatzerweiterung beim bauen von Ports noch nie bei mir Probleme bereitet haben, führen sie beim Bauen der Welt oder des Kernels immer zum Abbruch.

Hi, also ich habe zweimal problemlos (PC-BSD 0.8.3) die Welt, Kernel, Ports also komplett alles gebaut mit diesen Einstellungen;

CPUTYPE=athlon64
CFLAGS=-O2 -mmmx -msse -msse2 -msse3

Heute habe ich keine Lust mehr aber morgen werde ich das (CFLAGS=-O2 -mmmx -msse -msse2 -msse3 -m3dnow -mfpmath=sse)
probieren ..na mal sehen bin selber gespannt.

Gruß iptraf
 
iptraf, dir ist schon klar, dass du real keinen Geschwindigkeitsgewinn verbuchen wirst?
 
OOZE schrieb:
iptraf, dir ist schon klar, dass du real keinen Geschwindigkeitsgewinn verbuchen wirst?
wozu macht man das ganze dann?
also ganz ehrlich ich hab noch nie an meiner prozessoroptimierungen gemacht, hab abe rimmer wieder gelesen, dass das "gut" sei; ausserdem heisst "optimieren" ja das irgendetwas besser wird, also mal die frage in den raum wozu das ganze wenn die programme nicht schneller werden? oder ist das wieder so eine glaubenssache wo jeder meint er wuesste es besser? (gibts dazu keine empirischen studien?)


p.s.: hab meistens auf fertige packages gesetzt statt selber zu kompilieren, weil meine kiste so lahm ist, aber wollte demnaechst auch auf ein 64bit system aufruesten und dachte das es grade dann sinnvoll waere selber zu kompilieren :confused:
 
Dieser ganze compiler- und flag-Vodoo taugt schlicht und ergreifend gar nichts, genauso wie sinnloses und ständiges Herumfrickeln und Kernel oder sonstigen Teilen. BSD wird und wurde entwickelt, um default auf den allermeisten Maschinen/Situationen zu laufen.

Wenn man nicht spezielle Gründe hat da einzugreifen lässt man einfach die Pfoten von der Tastatur.

Und sowieso muss man sich fragen, was ein sse3 überhaupt bringen soll momentan, ich keine kein einziges Programm welches daruf fußt, auch die Zahl der ports welche ss2 benötigen ist marginal.

Aber egal, das kann man Millionen mal predigen, es hilft doch nichts. Optimiert weiter wenn es Spass macht.
 
Es sei noch hinzugefügt, dass speziell Welt und Kern extrem empfindlich auf einige Flags reagieren. Das mag im Moment zwar rein zufällig gerade mal klappen, aber für die Zukunft empfehle ich, wenigstens vom eigentlichen BSD-Kern alle Flags und Sondertools (wie z.B. ccache) fernzuhalten. Sowas kann den Buildprozeß empfindlich stören.
 
Daniel Seuffert schrieb:
Dieser ganze compiler- und flag-Vodoo taugt schlicht...
Deswegen hängt auch mein Pentium-M 1300 einige der Pentium 4 mit 2,4 GHz im Benchmark thread ab...

Natürlich bringt's was, sonst wären die Flags ja nicht da. Die Flags sind übrigens nicht für Programme gedacht die auf die Erweiterungen optimiert sind, sondern dafür das der Compiler die Erweiterungen auch bei Programmen verwendet, die nicht für die Erweiterungen angepasst sind. Wenn du SSE benutzt, hast du zum Beispiel einige Register mehr für Floating Point Operationen. Jeder der mal Assembler programmiert hat, weiß dass es in einigen Situationen ziemlich hilfreich ist viele Register zur Verfügung zu haben.
 
Natürlich nicht.

---update---
Daniels aussagen haben mich dazu bewogen genauer nachzuprüfen. Die Messungen fanden nicht unter optimalen Bedingungen statt, deswegen werde ich keine Zahlen nennen, sondern lediglich tendenzen beschreiben. Falls jemand mehr Klarheit wünscht, werde ich die Messungen unter anderen Bedingungen wiederholen.

Ubench wurde bei jedem durchlauf mit dem gcc41 kompiliert, hier ist die Rangliste mit den verschiedenen Flags und meiner Einschätzung.

1. -O2 -mmmx -msse -msse2 -mfpmath=387
Diese Flags brachten die beste Performance.

2. -O2 -mmmx -msse -msse2 -mfpmath=sse,387
Diese Flags lagen geringfügig dahinter.

3. -O2 -mmmx -msse -msse2
Der Unterschied zu 2 ist verschwindent gering.

4. -O2
Deutlich langsamer als 1, 2 und 3.

5. -O2 -mmmx -msse -msse2 -mfpmath=sse
Überraschenderweise war das mit Abstand am langsamsten. Von 4 auf 5 ist der Geschwindigkeitseinbruch nocheinmal halb so groß wie von 1 auf 4.
 
Zuletzt bearbeitet:
Ich kriege bei ubench auch mit den o.g. Flags keine besseren Werte. Schlimmer noch, mit jedem Durchlauf (egal, wie kompiliert wurde) bekomme ich schlechtere ubench-Werte.

Ubench CPU: 104513
Ubench MEM: 126182
--------------------
Ubench AVG: 115347

Das erscheint mir für einen 3700+ AMD64 ziemlich mies zu sein; ist allerdings bei laufendem kde, aber Deinen o.g. Powerflags.
 
Meine Messungen gelten nur für einen Pentium-M. Verlässliche Messwerte bekommst du wohl blos im single user mode.
 
Ich habe vor längerer Zeit (über 2 Jahre her) mal auf einer Testkiste scherzeshalber einige flags ausprobiert, bevor ich die Kiste platt gemacht habe. Ich konnte keinerlei signifikante Unterschiede feststellen ausser den üblichen probs. In Anbetracht der Tatsache, daß die meisten Kisten sowieso größtenteils idlen halte ich diesen ganzen Spass bis auf Sondersituationen für völlig überflüssig, dieses deckt sich auch mit meinen Betrachtungen im Forum und anderswo. Es mag Sonderfälle geben, aber das sind halt auch Sonderfälle. Und wenn ich mir die eventuellen Nachteile anschaue (z.B. -O2 im userland mit zahlreichen ports, die nicht damit laufen), dann komme ich zu dem Schluss, das dies geekrei ist, die nichts bringt. Aber da mag jeder seine eigenen Erfahrungen machen. Speziell bei Neulingen, die sich erstmal darauf konzentrieren sollten, eine wirklich laufende Maschine zu bekommen halte ich diese Gentooismen nach dem Motto ich installiere ein BSD und frage als erstes nach irgendwelchen "Optimierungen" für komplett daneben...
 
Ich betrachte das mit den Flags als Steckenpferd. In einer professionellen Umgebung würde ich auch blos -O2 -pipe verwenden.
 
also wie vermutet, der eine sagt es bringt was der andere sagt es bringt nichts...
ich glaube ich werde das ganze dann selber mal ausprobieren wenn ich einen schnelleren prozessor habe...
ich verstehe daniel einerseits, glaube auch dass wviel dieses kleingefrickeles ("gentooismus" passt uebrigens gut, die gentoo user die ich kenne meinen auch sie muessten an allen ecken irgendwas optimieren - ich sag nur "nene gnome frisst mir meine ganzen resourcen weg, deswegen nehm ich <minimalWM einsetzen>" bei einem 3,4ghz system mit 2gb ram) nur minimale vorteile bringt.
andererseits denke ich schon das diese flags zu irgendwas gut sein muessen, schliesslich bauen die herren und damen von intel und amd das zeug nicht zum spass darein, oder?

naja ein paar ordentliche benchmarks (auch in ner grafischen umgebung - ich verbring nicht genug zeit im singleuser mode um den schneller haben zu muessen) wuerden vielleicht trotzdem klarheit schaffen...
danke!
 
Hi, also ich finde die Unterhaltung hier sehr interessant und möchte dazu sagen dass eine konservative Haltung was Optimierung anbelangt in der Art „sicher ist sicher“ klar vorzuziehen ist. So habe ich meinen Debian durch FreeBSD 5.4 ersetzt, und da wird nix experimentiert das System an sich bleibt so wie es ist. Dank aber Wechselrahmen ist es mir möglich ein wenig zu experimentieren und das habe ich den ganzen Abend gemacht.... und die halbe Nacht... :)

Als Test System dient PC-BSD 0.8.3. Der Kernel wird immer mit; options CPU_ENABLE_SSE # SSE gebaut (Habe irgendwo gelesen..) CPUTYPE=athlon64 ist auch klar.


1) Buildworld & kernel mit;
CFLAGS=-O2 -mmmx -msse -msse2 -msse3 -m3dnow -mfpmath=sse
(Ohne Probleme)

CPU: AMD Athlon(tm) 64 Processor 3000+ (2386.39-MHz 686-class CPU)


FreeBSD 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #4:
Ubench CPU: 117508
Ubench MEM: 157082
--------------------
Ubench AVG: 137295

Aber ..KDE Startet sichtbar laaaangsammer so auch Programme..


2) Buildworld & kernel mit;
CFLAGS=-O2 -mmmx -msse -msse2 -msse3 -m3dnow -mfpmath=387

FreeBSD 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #4:
Ubench CPU: 120012
Ubench MEM: 159304
--------------------
Ubench AVG: 139658


Theoretisch kein großer Unterschied aber KDE Startet schneller, Programme lassen sich schneller ausführen ..das System ist sichtbar flotter geworden..so viel zu Benchmarks das sind eben nur nackte Zahlen;

CPU: AMD Athlon(tm) 64 Processor 3000+ (2520.02-MHz 686-class CPU)
FreeBSD 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #4:
Ubench CPU: 126627
Ubench MEM: 168987
--------------------
Ubench AVG: 147807

Die Flags aber, machen schon einen unterschied..zumindest auf meiner Kiste. :D
Gruß iptraf
 
Zurück
Oben