| Editorials : Alle bereit für Multicore? von rudi Fr, 15.September 2006
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.
 | | Acht Prozessorkerne wollen erst einmal richtig ausgelastet sein. | |
|
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.
[8 Leserkommentare] [Kommentar schreiben] Letzte Kommentare:
 | Markus 18:18 17.09. | | mdb hat folgendes geschrieben: Und ich hab geglaubt, wir reden von Kabel.
Du bist da draußen nicht allein. ;-)
Siehe...weiterlesen |  | mdb 21:09 16.09. | | slashCAM hat folgendes geschrieben: Alle bereit für Multicore? von rudi - 15 Sep 2006 10:20:00
>Nachdem die Webseite Anadtech gezei...weiterlesen |  | Christian Schmitt 11:37 16.09. | | Die Renderfarm dürfte er wohl hauptsächlich für die 3D Programme und vl Shake brauchen...
Und mit Gigabit Lan bleibt da auch nix stecken.
weiterlesen |  | (unregistered) 17:48 15.09. | | @Power Mac:
Können denn die Apple-Programme wie Motion oder FCP auf den Minis verteilt rechnen? Bliebt da nicht die Performance im Ne...weiterlesen |  | [ Alle Kommentare lesen]
[nach oben]
Weitere Artikel:
Editorials: Software-Patente in der EU doch noch verhindert Do, 7.Juli 2005
| Erfahrungsberichte: Sandy Bridge - Sinnvolles Overclocking und Hyperthreading Mo, 21.Februar 2011 Die neuen Sandy Bridge Prozessoren von Intel brauchen deutlich weniger Strom als ihre Vorgänger. Dies freut sicherlich alle Power-Anwender, deren Computer 24 Stunden am Tag durchrechnen und sich entsprechend auf die Stromrechnung auswirken. Doch auch für das Overclocking hat die geringe Stromaufnahme massive Auswirkungen...
| Erfahrungsberichte: Sandy Bridge - Unser Testsystem Fr, 18.Februar 2011 Bevor mit unseren Benchmark-Erkenntnissen loslegen, wollen wir auch noch kurz unser neues Sandy-Bridge Testsystem vorstellen... | Erfahrungsberichte: Sandy Bridge - Gedanken zur Grafik und Mainboardwahl Do, 20.Januar 2011 | Ratgeber: Was bringt Sandy Bridge für den Videoschnitt? Di, 4.Januar 2011 | Test: Apples iMac 27“ im slashCAM Rendertest Fr, 22.Januar 2010 | Grundlagen: 64-Bit – Vorteil für die Videobearbeitung? Mo, 26.Januar 2009 | Erfahrungsberichte: MacBook Festplattentausch und System-Umzug inklusive Bootcamp Di, 17.Juni 2008 | Test: MacBook – Late 2007 mit Intel X3100 Fr, 16.November 2007 | Test: Medienproduktion am MacBook Pro (1) So, 14.Oktober 2007 | Erfahrungsberichte: Selbstbau Schnittrechner Mi, 29.August 2007 | Ratgeber: Erste Einschätzung: QuadCore mit AMD und Intel Fr, 10.November 2006 |
[nach oben]
| |