Hallo Rüdiger, Am Mon, den 05.01.2004 schrieb Rüdiger Meier um 03:28:
Das hört sich immer subjektiv an, hast Du mal irgendwas nachgemessen?
Es ist erst mal definitiv subjektiv. Da Geschwindigkeit niemals der ausschlaggebende Grund für Gentoo bei mir war, habe nie irgendwas nachgemessen. Allerdings bekomme ich mit Gentoo unter der Quake3 Demo deutlich mehr FPS als bei Debian stable. Da waren locker 10 bis 15 Frames drin. Das kann aber auch am anderen Kernel und dem neuen Nvidia Treiber liegen.
Mich wunderts halt, daß bei SuSE alles nur für i586-Architektur kompiliert wird. Nur den Kernel gibts für Athlon und die glibc für i686
- scheint also in diesen beiden Fällen besonders viel Sinn zu machen. Bei der glibc interessiert es mich also, ob es sich lohnen würde diese für meinen AthlonXP zu optimieren.
Mmh, solange man da keinen objektiven Vergleich mit einer Maschine und zwei Systemen hat, kann ich Dir da nichts versprechen. Aber ich habe ja wie gesagt gestern Open Office 1.1.0 mit den aktuellen Ximian Patches durch den gcc gejagt und ich stelle definitiv einen Geschwindigkeitsschub beim Starten der Software fest. Vorher hatte ich die binaries von openoffice.org. Mal ganz davon abgesehen sind die Ximian Patches wirklich nicht schlecht, da sie OO beibringen CUPS zu verwenden und außerdem ein paar Schönheitskorrekturen vornehmen, die OO besser in Gnome und KDE integrieren. Empfehlenswert.
Ich hatte mal interessehalber ein paar Tests gemacht und z.B lame einmal für i586 und einmal für athlonXP+alle_möglichen_cflags kompiliert und auf ein grosses test.wav losgelassen. Der Performancegewinn lag unter einem Prozent! Bei transcode sah es auch nicht besser aus.
Es hängt eben davon ab, ob eine Anwendung von Prozessor-spezifischen Eigenschaften Gebrauch macht. Meines Wissens nach ist lame mehr eine P3/P4 Geschichte gewesen.
Deshalb wundere ich mich immer über den ganzen Aufwand den viele Leute betreiben, um ihre Programme selbst zu kompilieren, würde mich aber gern eines besseren belehren lassen, indem mir mal jemand ein messbares Beispiel für lohnenden Performancegewinn aufzeigt.
Wie gesagt, der Performancegewinn war für mich nicht ausschlaggebend. Mir ging es um die Möglichkeit, das System graduell auf dem neuesten Stand halten zu können. Dass Gentoo quellenbasiert ist, hat natürlich auch Nachteile, wegen der längeren Wartezeiten. Aber die gcc Optimierungen für bestimmte Architekturen werden schon ihren Berechtigungsgrund haben. Das Thema ist interessant und es wäre mal einen Bericht einer Fachzeitschrift wert, welche Unterschiede in der Geschwindigkeit man bei verschiedenen Distributionen feststellt. Vielleicht wirfst Du mal einen Blick auf gentoo.org und schaust in den Foren nach einer derartigen Diskussion. Ich bin sicher, dass es dort irgend ein Art von objektivem Vergleich gibt.
Hat Dein Kernel auch diesen desktop Bootparameter?
Nein. Ich denke, es wurde am Scheduler gedreht und die Art und Weise wie er einen Context Switch durchführt. Ich kenne mich wohl ein wenig mit Scheduling aus, aber habe keine Ahnung vom Linux Kernel im speziellen. Aber der Gentoo Kernel (2.4.x) wurde mit einigen Patches modifiziert, so dass er beste Desktop und Gaming Performance liefert. Hier findest Du eine Auswahl der Kernel, die für Gentoo verfügbar sind: http://www.gentoo.org/doc/en/gentoo-kernel.xml
Das wird wohl eher am Audio-Puffer (oder wie das heisst) liegen. Ich mache hier gerade aus gegebenen Anlass den povray-Test auf nem PI-200/SuSE-8.2 und xmms springt auch nicht.
So tief in der Materie stecke ich nicht, aber das Phänomen beschränkt sich nicht auf Audio Anwendungen alleine.
Erstaunlicher fand ich schon letzens auf nem Athlon-1800/SuSE-9.0, daß ich mit xine einen DivX-Film ruckelfrei anschauen konnte währenddessen transcode diesen erst aus einem VOB umwandelte.
Das ist in der Tat erstaunlich. Nicht schlecht.
Der eigentlich Grund, warum ich mich mit Gentoo so wohl fühle ist die Unabhängigkeit von RPM und seiner Abhängigkeitshölle, sowie die
rpm gefällt mir eigentlich ganz gut. Wer will kann die Abhängigkeitshölle hier mit --nodeps und --force leicht umgehen.
Und dann funktioniert die Software danach nicht, weil sie feststellt, dass Du sie mit einer veralteten glibc ausgetrickst hast ;-) Alles schon gehabt.
Naja,egal - wenn mein povray-benchmark irgendwann morgen Mittag fertig ist, schaffe ich's vielleicht bis morgen Abend povray für i386 zu kompilieren und weiss dann übermorgen Mittag ob diese sogenannte MMX-Technologie nicht möglicherweise doch nur ein Marketing-Gag der Neunziger war ;)
Es kommt eben darauf an, ob povray von den MMX Optimierungen Gebrauch macht. So etwas sollte auf der povray Seite nachlesbar sein. Dann macht ein neues Übersetzen eventuell Sinn. Grüße, Tobias