Ohne x86, aber mit AMD Radeon: Samsung arbeitet angeblich an Notebook-CPU

Top!
Finde Es klasse, das Du so gut auf das Forum eingehst.
Werde mal suchen, Was für Zen5 angedacht ist. Glaube 8+4 oder so.(x)
wait a minute
[Ins Forum, um diesen Inhalt zu sehen]

(x) Hat sicher Marketinggründe. Andersrum wäre evtl. auch gegangen.

Nein, eigentlich nicht oder nur in Ausnahmefällen. Meist ist es bei gemischten Workloads effektiver, mehrere kleine Threads auf einem big-Core zu bündeln und zusätzliche Kerne ganz wegzulassen. Nur wenn man fast ausschließlich little-Aufgaben hat und 1-2 Mainthreads zusätzlich bewältigen muss, könnte ein 2+16-Design sinnvoll sein. Aber das wäre eben sehr spezialisiert. Eigentlich glänzen Little-Designs eher in Szenarien, in denen die big-Kerne zeitweilig ganz abgeschaltet werden können. Aber da geht es dann um Effizienz, nicht Effektivität.

Nehmen wird die Zahlen aus dem PUBG-Test mal als abstraktes Beispiel und gehen pauschal davon aus, dass es sich um exakt 16 Threads handelt, von denen der heftigste im Broadwell-Fall einen Workload von "81 Punkten" verursacht:
Intel deutet in Folien einen 1:3 Leistungsunterschied an. Das heißt die Little-Cores erreichen maximal 1/3 der Leistung der Big-Cores (was bei 1/4 Platzverbrauch schon ganz gut ist) und könnten somit, wenn ein Big Core bei "81" limitiert, maximal Threads von Kaliber "27" bewältigen. Von unseren 16 Threads sind neben dem 81er auch der 59er und der 33er definitiv über dieser Grenze, der 27er bedenklich nah dran. Wir brauchen also mindestens vier Big-Cores, von denen drei aber etwas Luft haben. Genug Luft für sämtliche kleineren Threads – ich kommme bei gleichmäßiger Verteilung auf eine Kernbelastung von "81", "80", "80" und "71". Das heißt die optimale CPU für das gezeigte Anforderungsprofil ist ein 4+0-Design. 4+4 oder gar 8+x würden dagegen genauso durch den Mainthread limitiert, wie der getestete 8+0-Kerner, der Einsatz zusätzlichen Siliziums für weitere Kerne ist nicht effektiv.

Alternativ wäre es zwar möglich, den 27er und den 33er Thread auf einem gemeinsamen Big-Kern laufen zu lassen und denn entsprechend mehr verbleibende kleine Threads auch auf Little-Kerne zu verteilen. Ein 3+4-Design ist aber produktionstechnisch ungünstig und für eine 2+8-Big-Little-CPU müsste man sowohl den 27er als auch den 33er Thread aufteilen, denn beide passen weder in einen Little-Kern noch zusätzlich zum 59er in einen Big. Aber ehe man sich diese Mühe macht, sollte man lieber den 81er amgehen. Rechenbeispiel zwei: Eine optimierte Engine splittet den 81er in zwei Hälften und die größten Workloads wiegen 59, 41, 40, 33, 27 und in weiterer Folge 23 und 20 Punkte. Erstmal läuft das ganze Spiel dadurch bei gleicher Architektur und Takt jetzt bis zu 33 Prozent schneller, weil der 59er als Mainthread viel weniger limitiert. Das heißt aber auch, dass jetzt weniger Zeit für die Berechnung kleiner Threads zur Verfügung steht, ehe der nächste Frame ansteht – 1:3er Little-Cores kommen nur noch für Workloads mit 20 Punkten oder weniger in Frage, ehe sie zur Bremse werden. Um alle sieben genannten Mainthreads zu bearbeiten, brauchen wird also 5 Big-Cores (jeweils zwei kleinere passen zusammen auf einen), aber wiederum reichen deren sechs, um insgesamt ohne weitere Unterstützung auszukommen => Mit überarbeiteter Engine ist 4+8 zu lahm (zu wenig Big Cores), 5+1 ungünstig in der Herstellung, 6+0 genau passend und 6+x überflüssig. Also ist erneut eine all-Big-CPU die effektivste Wahl.

Oder bei Games mit schlecht ausbalancierten Threads/Core:

big.Little lohnt sich vor allem im ultra-low-power-mobile-Bereich. Also da, wo x86 nicht und ARM regelmäßig zum Einsatz kommt. Im Desktop wird der Nutzen eher gering sein beziehungsweise in der Einsparung von ein paar mm² Silizium bestehen. Das Intel bei Alder Lake darauf setzt, ist eher eine Kosten-Nutzen-Abwägung mit 0 Kosten: Man hat die zweite Architekturlinie seit den Atoms sowie im Haus, um damit Many-Core-Server-, Tablet- und Low-Power-Märkte unterhalb des Leistungsniveaus von zwei "großen" Core-Kernen zu bedienen. Jetzt beide Architekturen in einen Chip zu packen ist also mit vertretbarem Aufwand möglich und bringt Akkulaufzeit-Vorteile bei den Subnotebooks und den Tablets, wo sich Intel weiterhin hart gegen ARM, vor allem auch in Form von Chromebooks und jetzt Apple, kämpft. Man braucht diese Technik also sowieso und übernimmt sie einfach in die Desktop-CPUs, aber nur für diese zu entwickeln hätte sich nicht gelohnt. AMDs offizielle Position vor einem halben Jahr war noch "lohnt sich nicht, man kann gegenüber Zen 3 nicht genug einsparen" – und diese Einstellung war für eine Firma, deren kleinste Entwicklungen aus der 30-W-Notebook-Klasse stammen, auch vollkommen richtig. Mit dem dort üblichen Energiebudget und für die dort geforderte Performance ist man mit zwei aktiven plus weiteren, zeitweilig schlafenden Zen-Kernen sehr gut aufgestellt. Erst wenn man unter 10 W konkkurenzfähig sein wollte, müsste AMD etwas neues entwickeln.

Anm.: Es gibt APUs auch mit kleineren TDP-Einstufungen, diese Modelle sind aber runtergetaktete Ableger eines Designs, das eigentlich für größeres geschaffen wurde.

Das wurde wegen Ultramobil, die CPU+GPU+Chipsatz... dürfen nur 2 Watt konsumieren, gemacht. Da wird dann ab+an- geschaltet. Und für ~90% der Tätigkeiten reichen die little-Kerne: Standby-Modus.

Bei X86 wird schon länger P und C states verwendet:
[Ins Forum, um diesen Inhalt zu sehen]

[Ins Forum, um diesen Inhalt zu sehen]

Da bei all meinen Kernen Hintergrundlast anliegt sind die alle ein bisschen am Takten.