Die Nachricht lässt richtig Stimmung aufkommen. Bezahlbare Oktal-Systeme schon zum Jahresende. Damit hätte Anfang dieses Jahres wohl noch niemand gerechnet."Schuld" an diesen enormen Technologiesprüngen ist sicherlich der Prozessorkampf zwischen Intel und AMD, weil Intel aus seiner "Laissez-faire"- Haltung aufgewacht ist, um die schleichende Erosion der Marktanteile an AMD zu stoppen. Den Verbraucher kann und darf das wirklich freuen.
Ob sich die Software-Hersteller ebenfalls freuen steht dagegen auf einem anderen Blatt. Zwar war der Trend zu mehr Prozessorkernen schon vor zehn Jahren absehbar, jedoch bedeutet parallele Softwareentwicklung vor allem eines: Den gesamten Code umarbeiten oder besser gleich neu schreiben. Denn damit ein Programm wirklich mehrere Prozessoren sinnvoll und gleichmäßig auslastet muss man als Programmierer komplett umdenken.
Viele Programme bezeichnen sich heute schon als multiprozessorfähig. Bei genauerem hinsehen ist das jedoch nicht immer der Fall. Gerade in der Videobearbeitung scheint die Sache dabei ziemlich einfach zu sein: Jeder Prozessorkern bekommt ein separates Bild zugeschustert, das er abarbeitet und dann in einen Ram-Topf wirft. Bei einem Oktal System würde dann die Vorschau nach der Berechnung der ersten acht Bilder loslaufen und hätte somit (theroretisch) bei Echtzeit-Effekten eine vertretbare Latenz von 8 Bildern. In der Praxis gibt es jedoch Effekte (man denke an eine Zeitlupe oder einen temporalen Denoiser), bei der die vorangegangenen Bilder von den nachfolgenden abhängen. In so einem Fall kann ein einziger Effekt dann die gesamte Performance in den Keller sinken lassen. Und das sind noch eher kleine Probleme.
Aktuelle Betriebssysteme starten schon beim Hochfahren eine Unmenge mehr oder weniger sinnvoller "Threads", die nicht vorhersehbar Cache oder Prozessorlast beanspruchen. Also selbst wenn ein Programm die Aufgabe gleichmäßig verteilt, kann es nicht davon ausgehen, dass jeder Prozessor seinen Teil auch gleich schnell abarbeitet. Berechnungen die auf die (Multicore-) Grafikkarte ausgelagert werden werden, müssen ebenfalls sorgsam bedacht werden. Für eine wirklich effektive Verteilung sind also komplexe Strategien erforderlich, die sich nicht mal so eben in den Code einbauen lassen.
Dazu kommt, dass in Zukunft schlechter Code auch deutlicher "bestraft" wird. Denn wenn ein Programm gut über die Prozessorkerne skaliert, ein anderes aber nicht dürfte bei einem Oktal-System der Geschwindigkeitsunterschied deutlich größer ausfallen, als auf einem Single-Prozessor-System.
Auch die Betriebssysteme selbst skalieren mit den Prozessorkernen unterschiedlich. Gerüchte weise sollen Linux- und OSX etwas besser mit einer großen Prozessoranzahl umgehen können, als das aktuelle Windows-XP. Denn irgendwann verschluckt der Overhead (aka die Thread-Verwaltung) die zusätzliche Performance. So sind sich viele Hersteller einig, dass ab ca. 32 Prozessorkernen bei heutigen Systemen keine signifikante Geschwindigkeitssteigerung mehr erzielen lässt. So pauschal lässt sich das natürlich nicht sagen, da diese Voraussage sehr von der Problemstellung und dem zugrunde liegen Code abhängt.
Eines steht jedoch fest: Die nächsten drei bis fünf Jahre geht es nicht mehr um MHz sondern um die Anzahl der Kerne. Und eben um entsprechend angepasste Software. Wer näher über diese Fakten nachdenkt dürfte dabei vor allem zu einem Schluss kommen: Wir werden in Zukunft wohl weniger neue Funktionen in den Software-Paketen zu Gesicht bekommen. Stattdessen wird in erster Linie an der Engine gefeilt und die einzelnen Effekte Multiprozessor- und GPU-tauglich gemacht. Denn der Hersteller, der diesen Schritt jetzt nicht sauber und konsequent vollzieht, wird in naher Zukunft den übrigen Herstellern nur noch hinterher hecheln. Featureritis hin oder her.
