Cores

Kurz: Eigenständige Recheneinheiten innerhalb einer CPU — eine Mehrkern-CPU kann mehrere Befehlsfolgen gleichzeitig statt nacheinander ausführen.

Genauer: Früher hatte eine CPU genau einen Kern; heutige Prozessoren haben meist 4 bis 16+ Kerne. Software muss allerdings explizit für Parallelität geschrieben sein (Multithreading), um von mehreren Kernen wirklich zu profitieren — ein einzelner, sequenzieller Task nutzt immer nur einen Kern voll aus.

Im Detail

Warum Mehrkern-CPUs entstanden

Vor der Mehrkern-Ära ließ sich CPU-Leistung fast ausschließlich über die Taktrate steigern — mehr Rechenzyklen pro Sekunde bedeuteten direkt mehr Leistung. Mitte der 2000er-Jahre stieß dieser Ansatz an physikalische Grenzen: Höhere Taktraten erzeugen überproportional mehr Abwärme (die Verlustleistung wächst ungefähr mit dem Quadrat der Spannung und linear mit der Frequenz), die sich mit den damaligen Kühlmethoden nicht mehr sinnvoll abführen ließ. Die Antwort der Hersteller war, statt eines einzelnen, immer schneller getakteten Kerns mehrere, moderat getaktete Kerne auf denselben Chip zu packen — mehr parallele Arbeit statt mehr Tempo pro Arbeitsschritt.

Amdahls Gesetz: die Grenzen der Parallelisierung

Der entscheidende Haken dabei: Mehr Kerne bringen nur dann etwas, wenn die laufende Software auch tatsächlich mehrere Threads gleichzeitig ausführen kann (Multithreading) — ein klassisches, streng sequenzielles Programm (Schritt 1 muss fertig sein, bevor Schritt 2 beginnen kann) profitiert von zusätzlichen Kernen überhaupt nicht, da es ohnehin nur einen Kern auslasten kann. Dieses Phänomen beschreibt “Amdahls Gesetz”: Der Geschwindigkeitsgewinn durch Parallelisierung ist durch den zwingend sequenziellen Anteil einer Aufgabe begrenzt, egal wie viele Kerne zur Verfügung stehen — hat eine Aufgabe z. B. 10% streng sequenziellen Anteil, ist selbst mit unendlich vielen Kernen maximal eine 10-fache Beschleunigung möglich, nie mehr.

Performance-Kerne und Effizienz-Kerne

Neuere CPU-Generationen (z. B. Intels “Hybrid”-Architektur seit der 12. Core-Generation) kombinieren unterschiedliche Kern-Typen auf demselben Chip: leistungsstarke “P-Cores” (Performance-Kerne) für anspruchsvolle, zeitkritische Aufgaben und sparsamere “E-Cores” (Efficiency-Kerne) für Hintergrundaufgaben — ähnlich dem Prinzip, das aus ARM-basierten Smartphone-Chips stammt (dort “big.LITTLE” genannt). Das Betriebssystem muss dabei intelligent entscheiden, welche Aufgabe auf welchem Kerntyp am sinnvollsten läuft.

Kernanzahl in der Praxis

Manche Aufgaben lassen sich zudem grundsätzlich schlecht parallelisieren (z. B. wenn jeder Rechenschritt zwingend auf dem Ergebnis des vorherigen aufbaut), weshalb auch bei 16-Kern-CPUs die Leistung einzelner Kerne (Single-Core-Performance) weiterhin eine zentrale Kenngröße bleibt, gerade für interaktive Anwendungen wie Spiele, bei denen oft nur wenige Kerne wirklich stark ausgelastet werden. Für stark parallelisierbare Aufgaben wie Videokodierung oder das Kompilieren großer Softwareprojekte zahlt sich eine hohe Kernanzahl dagegen unmittelbar aus.

Kerne vs. Threads: die Unterscheidung

Wichtig ist die Abgrenzung zwischen physischen Kernen und logischen Threads: Technologien wie Hyper-Threading/SMT (Simultaneous Multithreading) lassen einen einzelnen physischen Kern zwei Befehlsströme gleichzeitig verwalten, indem ungenutzte Ausführungseinheiten innerhalb des Kerns besser ausgelastet werden — dem Betriebssystem erscheint eine 8-Kern-CPU mit SMT dadurch als 16 logische Prozessoren. Der Geschwindigkeitsgewinn durch SMT ist aber deutlich geringer als ein echter zusätzlicher physischer Kern (oft nur 10-30% mehr Durchsatz bei parallelisierbaren Aufgaben), da sich beide logischen Threads weiterhin dieselbe physische Rechenhardware teilen.

Wie das Betriebssystem Aufgaben verteilt

Die Verteilung einzelner Programme und deren Threads auf verfügbare Kerne übernimmt der “Scheduler” des Betriebssystems — er entscheidet in Sekundenbruchteilen fortlaufend neu, welcher Thread als Nächstes auf welchem Kern Rechenzeit bekommt, basierend auf Priorität, Wartezeit und (bei Hybrid-Architekturen) welcher Kerntyp am besten passt. Läuft ein Programm nicht explizit für Multithreading programmiert, bleibt es dabei stets an einen einzigen logischen Prozessor gebunden, egal wie viele weitere Kerne im System ungenutzt bereitstehen — ein häufiger Grund, warum manche ältere Software von zusätzlichen Kernen kaum profitiert.

Siehe auch: CPU, Threads, Takt (GHz)