Hallo,
bin gerade dabei ein paar Distributions-Tests zu durchforsten und bin dabei auf diesen Begriff gestoßen. Was ist damit jetzt gemeint? Sind alle Binaries auf einem i586er kompiliert worden? Oder ist der Kernel nur schon mit der Pentium Option versehen?
Ich danke für die
Beantwortung meiner Fragen
oooO Matze Oooo
Was sind CPU-optimierte Packete
Re: Was sind CPU-optimierte Packete
Hi,
manche Distros compilieren tatsächlich alles für i586. Doch die Kompatibilität mit i386/i486 aufzugeben für einen absolut nicht merklichen Vorteil ist das Dümmste, was man tun kann. Optimierung für i586 bedeutet nämlich, daß die Programme auf Pentium Pro, K6, P III usw. *nicht* optimal laufen. Am meisten würde es bringen, glibc für den spezifischen Prozessor zu optimieren und den Rest auf i386-Code zu lassen. Doch nicht einmal das ist möglich, weil gcc noch nicht so besonders für spezifische CPUs optimieren kann (OK, das könnte sich schon gebessert haben).
Bei den meisten anderen Programmen ist es einfach nur scheißegal, und dort wo es nicht so egal ist, compiliert man am besten selbst mit handselektierten Compileroptionen, profiliert dann das Ganze mit gprof und nimmt dann ggf. weitere Optimierungen im Quellcode vor.
Der Kernel hat auf das alles kaum einen Einfluß, mit Ausnahme der Grafikperformance, die stark von der Unterstützung der MTRR-Register abhängen kann.
Gruß,
hjb
manche Distros compilieren tatsächlich alles für i586. Doch die Kompatibilität mit i386/i486 aufzugeben für einen absolut nicht merklichen Vorteil ist das Dümmste, was man tun kann. Optimierung für i586 bedeutet nämlich, daß die Programme auf Pentium Pro, K6, P III usw. *nicht* optimal laufen. Am meisten würde es bringen, glibc für den spezifischen Prozessor zu optimieren und den Rest auf i386-Code zu lassen. Doch nicht einmal das ist möglich, weil gcc noch nicht so besonders für spezifische CPUs optimieren kann (OK, das könnte sich schon gebessert haben).
Bei den meisten anderen Programmen ist es einfach nur scheißegal, und dort wo es nicht so egal ist, compiliert man am besten selbst mit handselektierten Compileroptionen, profiliert dann das Ganze mit gprof und nimmt dann ggf. weitere Optimierungen im Quellcode vor.
Der Kernel hat auf das alles kaum einen Einfluß, mit Ausnahme der Grafikperformance, die stark von der Unterstützung der MTRR-Register abhängen kann.
Gruß,
hjb
Pro-Linux - warum durch Fenster steigen, wenn es eine Tür gibt?
-
gjw
Re: Was sind CPU-optimierte Packete
Wie wäre es denn mit einem ausfühlichen Artikel über verschiedenen Compileroptimierungen
(CFLAGS, CPPFLAGS) des GCC/GPP für Athlon, P3 & CO ?
Dieses übersteigt leider mein Wissen
export CFLAGS=-O3 -march=i686 ...
(CFLAGS, CPPFLAGS) des GCC/GPP für Athlon, P3 & CO ?
Dieses übersteigt leider mein Wissen
export CFLAGS=-O3 -march=i686 ...
-
Todde
Re: Was sind CPU-optimierte Packete
Au ja, dafür wäre ich auch!!!! <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
-
Sebastian Ude
Re: Was sind CPU-optimierte Packete
Naja, Compiler-Optimierung ist nicht alles.
Der Performance-Gewinn, den man durch Verwendung entsprechender Compiler (pgcc / AthlonGCC) und drastischer Optimierungs-Flags bei "normaler" Software bekommt liegt *maximal* bei 5 Prozent (natürlich gibt es ausnahmen).
In einer Linux-Gazette wurde mal abgehandelt, wieviel Sinn es macht, einen Kernel aus Performancegründen selber zu compilieren.
Im Bezug auf Compiler-Optimierung wurde gesagt (was auch meine Meinung ist) dass es viel bessere Möglichkeiten gibt, die gesamte Systemperformace zu steigern, z.B. mit hdparm IDE-Festplatten zu tunen.
Zwar wäre die Anwendung von hdparm sicherlich nicht ungefährlich, aber in der Zeit, die Leute aufgewendet haben um über Compiler-Optimierung nachzudenken, hätte man locker eine Controller- / Platten-capability-Database für hdparm aufbauen können (ist etwas wahres dran).
Und wenn man doch unbedingt beim Compilieren Optimieren will, so muss es im vernünftigen Rahmen bleiben.
Natürlich sind die Zeiten vorbei, als mit pgcc compilierte Anwendungen andauernd nur crashten und ein -O2 lebensmüde war.
Aber wenn ich so Sachen wie die Makefiles der glide3-libs sehe, wo mit -O6, -ffast-math, -fexpensive-optimizations und anderen "gefährlichen" Optionen optimiert wird, dann stehen mir die Haare zu Berge.
Mit diesen Flags hat bei mir auch der neueste pgcc keinen brauchbaren Code produziert.
Insgesamt ist es viel zu viel Aufwand für nichts, denkt lieber darüber nach anderweitig mehr Geschwindigkeit aus eurem System zu holen (Prozessor übertakten, Speichertiming runtersetzen, IDE-Platten mit hdparm tunen ... aber dabei bitte immer vorsichtig bleiben !).
Außerdem hat hjb Recht, ich würde niemals (auch auf einem LFS-System) Binaries für einen minimalen Performancegewinn von einem bestimmten CPU-Typ abhängig machen (-march ...).
Der Performance-Gewinn, den man durch Verwendung entsprechender Compiler (pgcc / AthlonGCC) und drastischer Optimierungs-Flags bei "normaler" Software bekommt liegt *maximal* bei 5 Prozent (natürlich gibt es ausnahmen).
In einer Linux-Gazette wurde mal abgehandelt, wieviel Sinn es macht, einen Kernel aus Performancegründen selber zu compilieren.
Im Bezug auf Compiler-Optimierung wurde gesagt (was auch meine Meinung ist) dass es viel bessere Möglichkeiten gibt, die gesamte Systemperformace zu steigern, z.B. mit hdparm IDE-Festplatten zu tunen.
Zwar wäre die Anwendung von hdparm sicherlich nicht ungefährlich, aber in der Zeit, die Leute aufgewendet haben um über Compiler-Optimierung nachzudenken, hätte man locker eine Controller- / Platten-capability-Database für hdparm aufbauen können (ist etwas wahres dran).
Und wenn man doch unbedingt beim Compilieren Optimieren will, so muss es im vernünftigen Rahmen bleiben.
Natürlich sind die Zeiten vorbei, als mit pgcc compilierte Anwendungen andauernd nur crashten und ein -O2 lebensmüde war.
Aber wenn ich so Sachen wie die Makefiles der glide3-libs sehe, wo mit -O6, -ffast-math, -fexpensive-optimizations und anderen "gefährlichen" Optionen optimiert wird, dann stehen mir die Haare zu Berge.
Mit diesen Flags hat bei mir auch der neueste pgcc keinen brauchbaren Code produziert.
Insgesamt ist es viel zu viel Aufwand für nichts, denkt lieber darüber nach anderweitig mehr Geschwindigkeit aus eurem System zu holen (Prozessor übertakten, Speichertiming runtersetzen, IDE-Platten mit hdparm tunen ... aber dabei bitte immer vorsichtig bleiben !).
Außerdem hat hjb Recht, ich würde niemals (auch auf einem LFS-System) Binaries für einen minimalen Performancegewinn von einem bestimmten CPU-Typ abhängig machen (-march ...).