Man sollte bei der News auch darauf hinweisen, dass das kein allgemeiner Guide für Softwareentwickler ist, sondern sich reine auf die Optimierung von Spielen bezieht.
Was die AVX-512 Unterstützung angeht, so handelt sich das um einen Fehler des Guides. Es ist definitiv nicht möglich mit Desktop/Notebook Alder Lake CPUs AVX-512 durch das Deaktivieren der Little Cores im BIOS freizuschalten.
Neodar schrieb:
Also haben gar nicht alle Alder Lake CPUs das "Big.Little" Prinzip? Aber genau diese "E-Cores" sollen doch die Systeme bei geringer Last so unglaublich Energieeffizent machen.
Sorry, aber das ist doch schon wieder übelster Murks, den Intel hier zusammengeschustert hat. Innert einer CPU Generation gibts also unterschiedlichste CPUs, die sich nun auch noch grundlegend in ihrer Kernzusammensetzung unterscheiden.
Mittlerweile muss man da ja selbst als etwas informierterer Käufer mit der Modelltabelle dasitzen, bevor man wirklich auf den "Kaufen" Button klickt.
Man muss eigentlich nur schauen wieviele Threads die CPU hat, denn 1 Big Cores mit 2 Threads durch SMT ist ziemlich genau gleich schnell wie 2 Little Cores, die auch 2 Threads abarbeiten.
Wenn man es genauer wissen will, dann muss man sowieso Reviews lesen oder sich zumindest die Performancetabellen ansehen. Ich wüsste nicht was da anders sein sollte als früher.
t3chn0 schrieb:
Was passiert wenn ein Entwickler ausversehen eine P App als E definiert? Gibt es auch Anwendungen mit Mischbetrieb? Kann ein Spiel auf E und P parallel zugreifen? Und woher weiß das Spiel, welche Bestandteile des Spiels wo laufen sollen?
Das Ganze funktioniert in der Regel so:
Das Spiel generiert Threads mit unterschiedlichen Aufgaben. Ein Thread kümmert sich z.B. im Hintergrund um die KI, ein Thread kümmert sich um das Nachladen von Texturen wenn man sich an den Levelrand bewegt usw.
Manche Aktionen lassen sich beliebig parallelisieren, manche Aktionenen lassen sich nicht parallelisieren.
In der Regel gibt es dann einen Thread, der die Framerate limitiert, da er nicht parallelisierbar ist.
Der Entwickler setzt nun die Piroritäten der jeweiligen Threads:
.) Der Main Thread bekommt hohe Priorität, damit dieser möglichst schnell abgearbeitet wird
.) Der Audiothread bekommt genauso sehr hohe Priorität. Dieser blockiert zwar nicht aber wenn dieser aussetzt gibt es unschöne Hacker
.) Alle Threads, die für die Berechnung des jeweiligen Frames verwendet werden aber nicht die limitierenden sind bekommen mittlere Priorität
.) Alle Threads die Hintergrundaufgaben durchführen bekommen niedrigere Priorität
Das reicht schon aus, damit das Betriebssystem die Threads ideal verteilen kann:
.) Threads mit hoher Priorität kommen auf die Big Cores
.) Threads mit niedriger Priorität kommen auf die Little Cores. Hier ist anscheinend die Strategie die Little Cores außerhalb von PL1 zuerst im Takt abzusenken, damit diese energieeffizienter werden, obwohl sie dies an sich von der Architektur bei normalen Desktoptaktraten nicht sind.
.) Threads mit mittlerer Priorität landen auf den verbleibenden Big Cores, wenn diese voll sind dann auf den Little Cores.
Falls ein Entwickler nun meint, dass er damit noch nicht ganz glücklich ist, kann er optional noch bei einigen Threads den gewünschten Kern festlegen.
Beispiel:
Der Audiothread hat zwar höchste Priorität weil er garantiert rechtzeitig ausgeführt werden muss, braucht aber nicht so viel CPU Leistung. Deshalb könnte dieser trotzdem auf einen Little Core verschoben werden solange garantiert wird, dass er dort auch wirklich laufen darf.
Wenn diese Optimierung ein Entwickler macht, dann sollte diese auch stimmen. Wenn das falsch gemacht wird, dann wird es schlechter laufen. Hier gibt es aber bei einer Spielengine deutlich schlimmere und nicht so offensichtliche Fehler, die man machen kann. Generell arbeiten hier schon Leute, die auch Plan von der Materie haben und keine Hobbyprogrammierer.
Im Prinzip sollte (mit Ausnahme der P/E Core Zuordnung) das bereits jetzt schon alles so gemacht werden. Die entscheidenden Unterschiede sind jedoch:
a) Einige Spielehersteller haben bisher die Anzahl der physischen Kerne dadurch bestimmt, dass sie die Anzahl der logischen Kerne (z.B. 8 bei einem Quad Core) ermittelt haben. Dann wurde geschaut, ob die CPU SMT unterstützt und falls ja durch 2 dividiert (8/2=4). Und dann hat man 4 Threads erzeugt, wenn man der Meinung war, dass SMT mehr schadet als es hilft (z.B. wenn der limitierende Main Thread einen Kern mit einem 2. Hintergrundthread teilen muss.
Mit Alder Lake ist es nicht mehr so einfach. Hier muss wirklich die gesamte Topologie ausgelesen werden. Beispiel: 12900K: 8 Big Cores mit je 2 Threads + 8 Little Cores mit je 1 Thread = gesamt 16 Kerne
b) Bisher konnte man auch auf die Prioritätenvergabe der Threads verzichten und stattdessen über die Theadpools nur so viele Threads spawnen wie physische Kerne verfügbar waren. Dadurch war auch sichergestellt, dass der Mainthread alleine ohne SMT auf einem eigenen Kern läuft (zumindest solange keine Hintergrundlast wie Virenscanner, Windows Update, Streaming im Hintergrund etc. dazu kommt). Bei Alder Lake ist die Annahme nur mehr bedingt sinnvoll und es könnte sein, dass der Mainthread gelegentlich auch einmal auf einem Little Core landet. Das ist bei bestehenden Spielen nicht die große Dramatik, da die Little Cores immer noch Skylake Performance haben (zumindest wenn sie voll getaktet sind), bei zukünftigen Spielen sollte man das jedoch unterlassen.