staging.inyokaproject.org

Hallo,

in letzter Zeit musste ich für die Uni einige kleine Programme in c/c++ selber schreiben und teilweise ging es auch um Performance. Da es mittlerweile zig Erweiterungen in Prozessoren gibt, z.B. die gefühlten 1000 verschiedenen Versionen von SSE, mit denen sich einiges beschleunigen lässt, stellt sich für mich die Frage, wie der Linux Kernel das nutzt.

Bei meinen Projekten musste ich beim Kompilieren entsprechende Flags setzen, bzw. wurde dies auch teilweise automatisch erkannt. Da aber meines Wissens viele Distributionen (wie Ubuntu) den Kernel bereits kompiliert verteilen, muss dieser ja so kompiliert sein, dass er abwärtskompatibel ist und dürfte ja eigentlich keine Erweiterungen nutzen. Das kann ich mir aber auch nicht wirklich vorstellen. Jetzt stellt sich für mich die Frage, ob das Verwenden der Prozessorerweiterungen keinen großen Vorteil beim Kernel hat oder ob das irgendwie anders durch "Magic" für meinen Rechner optimiert wird.

Nutzt der generische Ubuntu Kernel z.B. SSE4, welches einige Prozessoren bereitstellen? Kann ich durch bloßes Neukompilieren auf dem Zielrechner (ohne entfernen von Kernelmodule etc., mit der "originalen build-config") den Kernel effektiver machen?

Das Thema interssiert mich nämlich gerade und ich danke schon mal für jede Information ☺

Es bringt weniger als man hofft.

...und macht einen Haufen Arbeit. Solche "Optimierungen" würde ich nur in auswegloser Lage in Betracht ziehen.

DeJe schrieb:

Es bringt weniger als man hofft.

Richtig.

...und macht einen Haufen Arbeit.

Naja, wenn man weiß was man will, ist es schnell gemacht. Das Optimieren bis ins letzte Detail indem man Funktion xy weglässt, ist natürlich enorm zeitaufwendig. Aber eine Umsetzung der Idee

Kann ich durch bloßes Neukompilieren auf dem Zielrechner (ohne entfernen von Kernelmodule etc., mit der "originalen build-config") den Kernel effektiver machen?

geht halbwegs fix. Hey, er ist Student, er hat Zeit 😉

Wenn dir einfaches „Nö” nicht reicht, kannst du ja ein Benchmark machen, den Kernel kompilieren und anschließend ein weiteres Benchmark laufen lassen. Dabei natürlich auf keinen Fall das Backup vergessen!

Eventuell

IMO lohnt sich kompilieren für die meisten Anwender nicht.

Jedenfalls nicht, wenn das Ziel eine spürbare Geschwindigkeitsoptimierung ist. Auf einem normalen Desktop spielen andere Faktoren eine viel größere Rolle – alleine die Reaktionsgeschwindigkeit des Menschen vor dem Bildschirm, aber auch die Festplatte. Selbst wenn unter Laborbedingungen bei bestimmten Prozessen ein paar ms messbare Geschwindigkeitsunterschiede existieren, wird man die deshalb auf einem Desktop kaum wirklich ausnutzen können.

Dem gegenüber steht ein enormer Aufwand, um überhaupt zu kompilieren, das kostet viel Zeit und Energie – meiner Meinung nach holt man das auf einem Desktop nie wieder raus.

Aber du sagst ja, dass du für die Uni bestimmte Programme schreibst. Sind das lang laufende Simulationen, oder sowas in der Art? Also da könnte sich das vielleicht wirklich schon wieder lohnen, wenn z.B. so ein Prozess insgesamt 6h durchläuft und du mit den Optimierungen jeweils 40min einsparen kannst (immerhin gut 10%), dann … Go for it! Aber wie gesagt, das hängt stark davon ab, was genau du vorhast, ob sich diese Optimierungen bei dir auswirken und ob sich der Aufwand lohnt.

~jug

tzzz... Studenten haben doch keine Zeit! Immer diese Vorurteile 😉

Natürlich merkt man solche Optimierungen subjektiv erst wirklich, wenn man Programme schreibt, die dann statt 6h nur 5h20 laufen.

Ich wollte auch eher wissen, in wie fern der bereits kompilierte Kernel Prozessorerweiterungen wie SSE nutzt. Normalerweise wird ja zu Kompilezeit festgelegt, welcher Befehlssatz genutzt wird. Das würde bedeuten, dass der Kernel aber keine Erweiterungen nutzt. Eine andere Möglichkeit, die ich mir noch vorstellen könnte, wäre dass der Kernel zur Laufzeit feststellt welche Erweiterungen vorhanden sind in entsprechende "Module" lädt.

Warum nicht von Grund auf selbst optimieren?

http://www.linuxfromscratch.org/

Vielleicht waere aber diesbezueglich Gentoo eine bessere Alternative.

horst038 schrieb:

Ich wollte auch eher wissen, in wie fern der bereits kompilierte Kernel Prozessorerweiterungen wie SSE nutzt.

Ok, ich glaube dann haben wir deine Frage wohl etwas in die falsche Richtung verstanden. Also Ubuntu hatte früher™ bis einschließlich 10.04 zwei Kernelversionen, linux-image-generic und linux-image-i386, seit Ubuntu 10.10 ist die Version -i386 allerdings weggefallen. Ubuntu unterstützt mit dem Standardkernel nur noch Prozessoren ab i686 und neuer – das sind Prozessoren seit 1995. Bei den 64-Bit Systemen stellt sich diese Frage natürlich nicht, die gehören alle spätestens zur 886er Generation. 😉

Normalerweise wird ja zu Kompilezeit festgelegt, welcher Befehlssatz genutzt wird. Das würde bedeuten, dass der Kernel aber keine Erweiterungen nutzt.

Mit solchen Fragen habe ich mich noch nicht beschäftigt, sehr interessante Fragestellung jedenfalls. Mir ist das zu viel Raten und zu wenig Wissen, um da eine definitive Antwort zu geben.

Ich vermute einfach, dass der Kernel mit Rücksicht auf ältere Prozessorgenerationen so gebaut ist, dass keine neueren Befehlssatzerweiterungen aktiv genutzt werden. Aber kann er trotzdem Programme ausführen, die mit diesen Erweiterungen kompiliert wurden? Spannende Frage.

~jug

Das ist eine interessante Fragestellung, die sich mir auch schon gestellt hat. Werden die neuen Befehlssätze überhaupt genutzt?. Seit 1995 hat sich in der Prozessorwelt ja einiges getan. Ich würde diese Frage aber nicht nur auf den Kernel beziehen. Meiner Meinung nach sind die eingesetzten Programme ebenfalls interessant - zumindest diejenigen, die viel Rechnen müssen: Numerische Tools (octave,...), Videobearbeitung (ffmpeg,...).

Ich hatte mal einen Test gemacht: Numerische Berechnungen mit octave mit der vorkompilierten Version, die Ubuntu 32 Bit mitbringt. Die gleiche Rechnung auf einer selbst kompilierten Version (für meine CPU) von octave. Die zweite Variante war ca. 5% schneller, wobei mein Berechnung nur einen minimalen Teil des Umfangs von octave nutzte.

Teilweise gibt es auch verschiedene Pakete für unterschiedliche Prozessoren. Für Lucid bspw. gibt es für die "libatlas" Bibliothek (algebraische Rechnungen) verschiedene Pakete, die alle das gleiche tun (jedoch unterschiedlich schnell):

libatlas3gf-base (für ältere CPUs natürlich)

libatlas3gf-3dnow

libatlas3gf-sse

libatlas3gf-sse2

Die libatlas3gf-sse2 ist bei linearen Matrix-Operationen z.B. um ein Vielfaches schneller als die libatlas3gf-base. In diesem Fall würde es sich lohnen, die Bibliothek selbst zu kompilieren, wenn es sie nicht speziell für neue CPUs schon geben würde.

Nur so als Einwurf...

Ein selbstkompilierter Kernel bringt heutzutage eigentlich nichts mehr, da bringt der Einbau einer SSD schon wesentlich mehr. Zudem muss man einen Selbstgestrickten auch selbst pflegen. In den Anfängen war es natürlich oft unumgänlich sich einen Kernel auf seine Hardware zu optimieren. Wenn man Lust und Zeit hat kann man das natürlich noch immer machen, ob dabei was Besseres rauskommt bezweifele ich.

Da der Kernel ja vermutlich relativ wenige FP-Operationen nutzt, kann ich mir nicht wirklich vorstellen, dass SSE einen erheblichen Einfluß auf die Geschwindigkeit haben kann. Der einzige größere Einfluss sollte eigentlich die Menge der verfügbaren Register sein, aber durch schnelle Caches und Register Renaming bin ich mir selbst da nicht sicher, ob man da noch einen Einfluss merkt. Insgesamt sind glaube ich bei 64bit die meisten für den Kernel relevanten Befehle verfügbar. In den meisten Fällen verursacht der Kernel ja ohnehin nicht gerade einen rießige CPU-Last, echte Auswirkung auf die Gesamtgeschwindigkeit kann ich mir deshalb sowieso nicht vorstellen.

Noch eine kurze Anmerkung zu Programmen, die von speziellen Befehlen stark profitieren können (Video-encoding etc.): hier gibt es eigentlich die Möglichkeit, verschieden Code-Pfade im Programm zu haben, die jeweils andere Befehle nutzen. Das Programm stellt dann zur Laufzeit fest, was der Prozessor alles kann und wählt den entsprechenden Code-Pfad (weiß nicht in wie weit das bei OSS gemacht wird, weil man ja eigentlich neu kompilieren könnte).

OT:Intel hat sich da z.B. mal...ungeschickt...angestellt. Ihre Compiler (ICC, IFORTRAN) haben diese verschiedenen Code-Pfade für SSE etc erstellt, aber auf AMD-CPUs wegen eines "Bugs" immer den langsamen i368 Pfad gewählt. Da der ICC recht gut und verbreitet ist, wurden auch manchmal Benchmarks mit ihm kompiliert (Quelle z.B: http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Criticism ). Bei Phoronix oder irgendwo gab es auch mal einen relativ neuen Benchmark zu Speicherzugriffen, wo die AMD CPU erheblich gewonnen hat, wenn sie sich fälschlicherweise als "Genuine Intel" ausgegeben hat.

Bin jetzt grade nicht zu 100% sicher informiert, würde aber sagen:

• 64bit builds nutzen glaube ich schon sse2, mehr Register usw...ist Teil der Grunddefinition von x86_64

• Sse(2/3) ist auch für nicht-fliesskomma Anwendungen relevant, da durchaus auch integertypen/Operationen unterstützt werden!

• Der Kernel selbst ist nicht so der Flaschenhals, eher die Anwendung selbst, die läuft. Höchstens noch benutzte Bibliotheken, und die libc

• In der Vergangenheit war's jedenfalls so, dass man bei gcc mit -march, aber vorallem auch mit -mtune leistung 'rausholen konnte, wenn man den verwendeten Prozessor genau kennt, und das Prog nur auf diesem läuft. Ich weiss jetzt allerdings nicht wie "gut" gcc bei den aktuellen cpu's ist, und ob sich die Unterschiede lohnen - einfach mal testen!