Wie schwer ist es, Software für Multi-Core-CPUs zu optimieren?
Eigentlich nicht. Wobei es da mehrere Anwendungsfälle gibt:
Auslagern von I/O oder einzelnen Langläufern auf eigene Threads oder Forks, die dann auf einem eigenen Core laufen: Das ist in der Regel eine einfache Angelegenheit, insbesondere, wenn Rückgabewerte nicht benötigt werden. Druckaufbereitung oder langwierige Datenbankabfragen sind Beispiele hierfür. Der Benutzer kann im Vordergrund weiterwerkeln, während im Hintergrund hart gearbeitet wird.
Parallelisierung von Berechnungen: Hier muß darauf geachtet werden, daß die einzelnen Berechnungen unabhängig von den anderen laufen. Dann ist das wieder eine einfache Sache, man muß nur die Ergebnisse am Schluß zusammentragen.
Module, die lose gekoppelt sind: Hier meine ich eine Anwendung, bei der Daten von Modul zu Modul weitergereicht werden. Wenn man es geschickt anstellt, kann die Arbeit verzahnt werden: Die Daten kommen als Paketstream und werden paketweise verarbeitet und weitergereicht. Dadurch können die Arbeitsschritte teilweise parallel laufen.
Trennung von Backend und Frontend: Während das Frontend in eigenem Thread stets bereit ist, Eingaben vom Benutzer entgegenzunehmen, arbeitet das Backend auf einem oder mehreren eigenen Thread(s) die Anfragen ab und kommuniziert mit dem Frontend. So muß der Benutzer nicht zwischen Eingaben warten, bis diese abgearbeitet siind.
Multiuser-Systeme: Die Erweiterung des letzten Punkts auf mehrere Frontends, die mit einem Backend arbeiten (zB bei Webapplikationen). Um hier halbwegs vernünftige Antwortzeiten zu erhalten, kommt man um eine Verteilung der Arbeit auf mehrere bis sehr viele Threads, vor allem im Backend, gar nicht herum - und damit machen viele Cores, auf die die Arbeit aufgeteilt wird, richtig viel Sinn.
Generell gilt: Bei mehreren Threads machen mehrere Cores immer einen Sinn.