Zitat:
Original geschrieben von kikakater
Das sind Speicherverwaltungsprobleme unter Multiuser-, Multitask- und Multithreadumgebungen wie es Linux nun einmal komplexer darstellt. Es wurde auch nicht auf Speichermodelle wie 512 MB RAM maximal vorhanden, 1 GB RAM maximal vorhanden usw. optimiert.
Windows ist halt ein Clientsystem par exellance, deswegen geht es etwas bis um einiges schneller.
Das wird wie gesagt bis zur Einpassung in solche RAM Größen Modelle auch so bleiben.
Es geht um das Bilden von Pools (große zusammenhängende Speicherbereiche für Programmdatenbereiche), die augenblicklich auch verworfen werden können müssen ( Deutsch  ), das tut Windows, Linux hat noch eine antiquiertere abgeschottete Speicherverwaltung, das kann grundsätzlich auch so bleiben, allerdings müssten vom Betriebssystem her die Speicherbereiche schneller wieder freigegeben werden können für neue Prozesse. Außerdem müssten die Binärdateien auf der Festplatte optimiert umgeordnet werden, damit das Laden schneller vonstatten geht.
So weit von der Ebene des Systemprogrammierens her ... der X Server tut mit seinen metaähnlich aufgebauten Aufrufen auch sein Übriges dazu bei, daß es unter Linux sehr viel gemächlicher zugeht als unter Windows.
Die Probleme sind in den Griff zu kriegen, vor allen Dingen würde die Übernahme von Code von BeOS für Linux - speziell was den X Teil anbelangt (in diesem Zusammenhang kann man den Terminal Server nennen) - sehr viel (mehr) bringen.
Für Linux läuft die Sache auf ein RTOS (Real Time Operating System) Interface in Sachen Framebuffer (Speicherinhalt des Bildschirms) hinaus.
Es war von Anfang an klar, daß Linux Windows in diesen Bereichen um Längen hinterher hechelt.
Derzeit ist die ultimative Frage, ob Treiber in frei erhältlichen ISO Images vorhanden sind oder vom Systemverwalter des Desktopcomputers nachträglich integriert werden müssen.
Da bleibt dann nicht die Muße, auf solch eine Mannkapazitäten fordernde Materie, wie Ablaufbeschleungigung von Systemroutinen und Anwendungen näher einzugehen, geschweige denn, sie ernsthaft einer Lösung zuzuführen.
|
Ich habe leider kaum Ahnung von Systemprogrammierung, aber was du hier von dir gibst, lässt mich darauf schließen, dass es bei dir so ähnlich aussieht :>
@Initial Post:
Welche Auflösung und Farbtiefe fährst du, bei welchem Treiber? Wenn du eine nvidia-Grafikkarte hast, würd ich, auch für den 2D-Bereich, zum proprietären treiber raten; auch wenn es schmerzt - aber der ist einfach um ein gewaltiges Stück fixer als "nv".
Außerdem könntest du deinen X-Server, und auch Mozilla, mit GCC 3.4 neukompilieren, das bringt mindestens 15% mehr gefühlten Speed, behaupte ich jetzt mal. Wer's nicht glaubt: ausprobieren!
Eventuell kompilieren die im Moment verfügbaren Sourcen auch mit -ffast-math, das würde dem ganzen noch einma mehr Speed geben, sodass man am Ende einer GDI++-basierten Windows-Umgebung wahrscheinlich sogar überlegen gegenübersteht.
Und ad Programmladezeiten: Prelinking und -Os sind die Freunde des Ungeduldigen.
Und ad Speicherfragmentierung: Kernel mit 4K Stacksize kompilieren löst das (imo nicht signifikante) Problem.
Threadlastige Applikationen kann man übrigens durch den Einsatz der NPTL nochmal ordentlich beschleunigen. Weiß allerdings nicht, ob Mozilla auch davon profitiert.