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.
Zurück zum Artikel: Ohne x86, aber mit AMD Radeon: Samsung arbeitet angeblich an Notebook-CPU
