1.) Das Problem an der Verteilung ist, dass es nicht einfach 4 Prozesse gibt, die je eine CPU belegen. In der Realität gibt es 70 Prozesse mit insgesamt 500 Threads, wovon 498, einer der Virenscanner ist, der im Hintergrund ein bisschen dran scannt und einer macht die gesamte Arbeit. Hier ist sehr wohl das Problem, dass man diesen Thread parallelisieren muss und in mindestens 4 aufteilen, die alle gleichmäßig arbeiten. Die 498 Threads die nichts tun waren noch nie das Problem und werden es auch nie sein.
2.) Das Problem an der Parallelisierung ist, dass es erstens Alogorithmen gibt, die sich nicht parallelisieren lassen bzw. viel Code würde sich zwar parallelisieren lassen, man würde aber durch die Synchronisierung so viel verlieren und sich so viele mögliche Bugs eintreten, dass das alles nicht mehr praktikabel ist. Hier wäre ein guter Ansatzpunkt für künftige Betriebssysteme diese Performance zu verbessern.
Ein weiteres Problem ist, dass man in den seltensten Fällen einen Codeteil hat, der viel rechnet. Man hat mehrere Unferfunktionen, die in Summe viel Zeit kosten. Eine Parallelisierung auf unterer Ebene in der Bibliothek z.B. ein Zugriff auf das Dateisystem, ein einfaches SQL Kommando etc. ist nicht komplex genug, als dass sich eine Parallelisierung lohnen würde. Auf oberer Ebene würde sich die Arbeit durch das Ganze Programm ziehen, statt lokal in einer gut getesteten Standardbibliothek zu halten. Hier wäre der Aufwand für die Tests meistens viel zu hoch und man würde sich eine Menge möglicher Bugs eintreten. Gerade Bugs in Bezug auf Threads sind sehr gefährlich, da sie meistens nicht reproduzierbar sind, geschweige denn dass man die Ursache in der Entwicklungsumgebung mit Breakpoints finden könnte. Oft scheitert es auch daran, dass man Ressourcen verwendet, die nicht parallelisierbar sind z.B. eine TCP Verbindung kann nicht von 2 Threads gleichzeitig verwendet werden.
3.) Bei steigender Parallelisierung (Many Core) wird der Speicher ein immer größeres Problem. Die Bandbreite kann beim RAM beliebig erhöht werden, indem die Anbindung breiter wird, jedoch die Latenz kann nicht gesenkt werden. Da eine starre Zuordnung von Speicher zu Prozess in einer CPU auch nicht sinnvoll ist, muss es Wege geben, parallele Zugriffe zu ermöglichen. Dies könnte z.B. passieren, indem der Cache pro Kern stärker fokusiert wird und der RAM in mehrere Bereiche geteilt wird. Es wäre z.B. möglich jeden Chips getrennt zu adressieren. Hier kann es zwar auch zu Überschneidungen kommen, die Wahrscheinlichkeit ist aber geringer. AMD hat diesen Versuch schon mit einzelnen Modulen mit Ganged vs. Unganged Mode unternommen.
4.) Bei halbwegs vernünftiger Verwendung ist die CPU in Desktop Rechnern nicht die bremsende Komponente, sondern die IO Zugriffe. Ein Virenscanner, der ohne brauchbare Prioritätsvergabe die Festplatte komplett auslastet, um den wöchentlichen Full Scan zu machen ist die Hölle.
In vielen Fällen ist es jedoch nicht einmal die Hardware selbst, was durch SSDs in Zukunft verbessert werden könnte, sondern das IO System an sich. Es werden im Hintergrund Unmengen an Zugriffen auf die Registry durchgeführt bzw. auf das Dateisystem (Cache), ohne die Dateien selbst zu lesen. Jeder dieser Zugriffe ist zumindest ein Context Switch d.h. ein Prozess gibt die CPU ab und wartet auf die Antwort des Systems.
Hier könnte man ansetzen, dass einige Zugriffe durch Events gelöst werden und nicht durch Polling. Das typische Problem ist ein Dienst, der Änderungen an der Config auch ohne Neustart übernehmen soll. Dieser kann ständig die Registry abfragen. Hier müssten Methoden eingeführt werden, einen Empfänger automatisch zu benachrichtigen und das Ganze in einer Form, dass es der normale 0815 Programmierer, der die Windows API nicht auswendig kennt auch benutzen kann.
5.) Ein weiteres Performanceloch sehe ich beim Booten des Rechners bzw. allgemein beim Starten von Programmen. Hier werden Unmengen an dlls geladen, Einstellungen verarbeitet etc., was vielen Fällen gar nicht notwendig ist, aber auf manchen PCs sehr wohl benötigt wird. Hier muss die "Load on first use" Philosophie noch weiter ausgebaut werden, dass Dienste erst gestartet werden, wenn diese benötigt werden bzw. dlls erst geladen werden, wenn sie wirklich gebraucht werden, Konfigeinstellungen nur verarbeitet werden, wenn der Teil der Software auch benötigt wird z.B. würde es bei ICQ reichen, wenn die Verbindung zum Server aufgebaut wird. Der Rest kann geladen werden, falls eine Nachricht kommt bzw. man selbst das User Interface öffnet. Oft wird die Quickstart Funktion auf wenigen Rechnern dringend benötigt, auf anderen Rechnern wird die Software selbst nie angerührt.
