Neue Prozessoren und neue Software

Ich habe gerade einen Bericht über die Architektur von Intels neuem Prozessor Core I7 gelesen. Er führt wieder neue Befehle ein, mit denen man z.B. Strings besser vergleichen kann und die Stringlänge schneller bestimmen. Vor allem gibt es wieder Hyperthreading und neue Hardware Features, wie das komplette Stilllegen von Kernen oder das Hochtakten der anderen Kerne wenn einige stillgelegt sind.

Das ganze erinnert mich an eine Grundproblematik, die wir eigentlich seit dem Pentium II haben. Bis dahin war es so, dass die Prozessoren die Befehle immer schneller ausführten, entweder weil sie weniger Takte pro Befehl brauchten oder die Taktfrequenz anstieg. Es gab gravierende Erweiterungen in der Architektur: Mit dem 80286 den Protected Mode und eine 16 MByte Adressierung und mit dem 386 den vollen 32 Bit Modus mit 32 Bit Registern und 32 Bit Adressierung. Aber: Software musste dafür entwickelt werden und dann konnte die Software auf allen Rechnern das gleiche – egal ob sie auf einem Pentium oder 386 er lief.

Seit dem Pentium II wird an der Architektur geschraubt. Es wurde eine zusätzliche Unit eingeführt: SSE, die mittlerweile bei SSE 4.2 angekommen ist. Mal gibt es Hyperthreading, mal nicht. Prozessoren gibt es mit 2, 3 oder 4 Kernen. Eine Zeitlang gab es auch nur 32 Bit fähig waren und welche mit 32 und 64 Bit Kernen.

Sieht man sich die SPEC Benchmarks an, bei denen die Hersteller der Prozessoren die Freiheit haben den Compiler so einzustellen, dass er den optimalen Code erzeugt, dann sind teilweise große Sprünge in der Performance möglich: 20-30 5 mehr bei gleicher Taktfrequenz mit einem neuen Kern und Optimierter Software. Doch haben Sie etwas davon?

Nein. Denn ein Hersteller von Software kann diese nicht auf einen Prozessor optimieren. Er kann nicht die neuesten Befehle einsetzen, wenn er nicht einen Großteil der Kundschaft verprellen will, die diesen Prozessor nicht hat. (Vor allem nicht wenn AMD und Intel zueinander inkompatible Erweiterungen machen). Ja heute ist – einige Jahre nach Einführung der Zweikernprozessoren – es noch normal, dass eine Software nur einen Kern ausnutzt,. Das ist aus der Programmierung zu erklären, die erheblich aufwendiger wird, wenn man mehrere Prozesse abstimmen muss. Sehr oft ist aber auch der Arbeitsablauf linear. Der Zweikernprozessor bringt trotzdem etwas: Denn das Betriebssystem kann ganze Programme zwischen den Kernen verschieben. So bleibt ein Kern für die Arbeit und einer für Hintergrundtätigkeiten (Virenscanner, Download, Videostreaming). Doch mehr braucht man nicht: Vierkernprozessoren haben bei den Wald und Wissen Anwendungen keine Vorteile. Für Gamer werden sogar Zweikernprozessoren empfohlen – Sie sind höher getaktet und es gibt noch kaum Spiele die mehr als zwei Kerne nutzen.

Wie soll dies weitergehen? Man wird wohl kaum den Fortschritt einfach aufhalten können. Ich sehe zwei Möglichkeiten. Die eine getrieben von den Hardwareherstellern: Sie legen eine Hardwareplattform fest die so mächtig ist, dass es Jahre dauert sie vollständig umzusetzen. Bis dahin emuliert man sie und nach und nach füllt man sie mit Leben. Z.B. einen 64 Kernprozessor. Derzeit können wir nur 4 Kerne produzieren. Diese müssten die anderen mit emulieren und dabei eben dauernd wechseln. Oder eine 128 Bit Umgebung mit sehr mächtigen Streaming Operationen, Codierungs- und Encodierungsoperationen in Hardware oder High-Level Befehle als Maschinensprache. Auch das ist nicht undenkbar. Sie sind jetzt vielleicht nicht möglich und müssen bis dahin durch ein kleines Programm ersetzt werden. Doch das ist nichts neues: Der 8086 konnte auch nicht Multiplikation und Division in Hardware ausführen. Das machte ein kleines Microcodeprogramm. Software wird dann laufend schneller in dem Maße wie die Hardware die Emulation durch real vorhandene Hardware ersetzen kann. Solange kann aber ein Hersteller seine Software unverändert über Jahre hinweg einsetzen und sie wird immer schneller.

Der zweite Weg wird von den Softwareherstellern beschritten: Betriebssystemherstellern und Softwareproduzenten. Wenn ich will, dass meine Software immer optimal läuft, dann muss ich sie neu kompilieren. Nun will ein Softwarehersteller sicher nicht seinen Code herausgeben. Das ist aber notwendig um sie neu zu kompilieren. Eine Lösung wäre es den Quelltext zu verschlüsseln  z.B. mit einem 256 AES Schlüssel. Wenn eine Kompilierung notwendig ist fragt der Compiler nach dem Schlüssel beim Hersteller nach und bekommt ihn. Damit erzeugt man eine optimale Version für den eigenen Prozessor und man wahrt trotzdem das Geheimnis des Codes. Das Kompilieren muss dabei fest in das Betriebssystem eingebunden werden und dieser muss sich gegenüber dem Hersteller als sicher ausweisen können z.B. mit einem Zertifikat. Ein Hersteller kann sogar mehrere Versionen von besonders kritischen Teilen vorhalten, optimiert für verschiedene Prozessoren.

Eine Alternative, aber weitaus schlechter optimierend wäre ein Programm welches den Quelltext untersucht und Optimierungen vornimmt, z.B. Befehle durch leistungsfähigere ersetzen oder Programmteile in einzelne Threads unterteilen. Diese Lösung kommt ohne Kenntnis des Quelltextes aus, ist jedoch nur suboptimal .NET hat dies angekündigt, doch bislang sieht man keine besondere Unterstützung von leistungsfähigen Features einzelner Architekturen.