News Alder Lake: Unzählige Varianten von Intels big.LITTLE-Prozessor gesichtet

[xexex]

Wenn man sich die Werbung anguckt die es in der Vergangenheit gab, dann wird salopp mit einer 8-Kern-CPU mit 3 GHz Takt geworben, obwohl es eigentlich nur 2 Kerne sind die überhaupt so hoch takten können und der Rest sich dann in 4 Mittelklasse-Kerne mit 2 GHz

Hast du dir mal die Werbung heutiger CPUs angeschaut? Dort wird auch mit 5Ghz geworben, obwohl dieser Takt meist nur auf einem oder zwei Kernen gefahren werden kann. Bei voller Auslastung fallen dann alle Kerne auf 4Ghz oder noch weiter runter. Einen wirklichen Unterschied gibt es an dieser Stelle also in der Praxis eigentlich nicht, die wenigsten CPUs können den beworbenen Takt auf allen Kernen fahren, geschweige denn dauerhaft halten.

Der Gedanke hinter big.LITTLE dürfte auch sein, wenn ich sowieso schon wegen dem Powerbudget den vollen Takt nur auf x-Kernen fahren kann, wieso dann überhaupt x vollständige Kerne auf einer CPU packen. Angenommen die 8+8 Kerne können dann allesamt mit voller Geschwindigkeit genutzt werden, erreicht so eine CPU höchstwahrscheinlich mehr Leistung, als eine die bei Volllast mit angezogener "Handbremse" läuft.

 

[C.J.]

Wow du hast es aber ausführlich formuliert,dennoch sind weitere Fragen übrig geblieben.
Woran merkt man denn das ein Programm nur Integer Berechnung macht und es in den L1 Cache Passt und wann es auch Fließkomme Einheit benützt.

Als User kannst du sowas nicht nachhalten, weil dir kein Tool die interne Auslastung einzelner Kerne so feingranular anzeigt. Du musst ja auch bedenken, dass das ein Extrembeispiel von mir war, um zu verdeutlichen wie es sein kann, dass ein Kern zwar intern nicht voll ausgelastet ist, aber trotzdem "mit 100%" läuft. In der Praxis ist das alles noch viel komplizierter. Nur mal ein Schaubild um zu sehen, was in so einem Kern alles drin ist: https://en.wikichip.org/w/images/f/f2/zen_2_core_diagram.svg

In jedem Takt werden eine andere Kombination an Einheiten unterschiedlich stark ausgelastet, abhängig davon wie der Instruktions-Strom aussieht, den der Kern abarbeitet. Alle Teile durchgehend voll zu beschäftigen ist quasi ausgeschlossen.

-Zitat entfernt-

Aktiviertes AVX macht ein Programm nur dann schneller, wenn es auch AVX-Befehle nutzt. Ein 3950X ohne SMT hat 16 Threads, keine 28. Wie die einzelnen Auslastungen zustande kommen, kann ich nicht sagen, aber es gibt ja ein eindeutiges Muster, nämlich dass die Auslastung schlechter wird, je mehr Threads du hast. Das erscheint logisch, denn je mehr Threads man hat, desto schwerer sind die auszulasten. Zum Thema "Kernschmelze": Die wirst du nicht durch Software erreichen können, weil eine volle Auslastung auf Transistorebene nicht möglich ist (s.o.).

Also noch ne frage,also ab 10 Kernen,zeigt mir es nach dem Umwandeln immer 18 Threads an.

Was heißt "zeigt mir immer 18 Threads an"? Wer zeigt das an und wie?

Wie bisher, "Resteverwertung". Aktuell konnte eine CPU nur als 8/16 oder 8/8 verkauft werden, in der Zukunft halt auch als 8+8, 8+4 oder 8+2.

Resteverwertung stimmt schon, aber die Kleinteiligkeit ist schon ein wenig lächerlich. Bei Lakefield sind die vier kleinen Kerne auf dem Chip so groß wie der große Kern. Wenn das bei Alder Lake so bleibt, dann sieht das Ding von oben wie ein "Zehnkerner" aus, nur dass zwei dieser Kerne in Wirklichkeit 4er Cluster von kleinen Minikernen sind. Soll heißen: Die Chance dass alle 8 großen Kerne gehen, aber die kleinen nicht ist sehr klein. Und wenn, dann werden nicht viele defekt sein. 8+8 und 8+6 sollten völlig ausreichend sein, quasi ein 12900K und ein 12700/12800K. Die CPU-Hersteller deaktivieren ihren L3-Cache ja auch nicht MB-weise und verkaufen dann 8C+16MB, 8C+14MB, 8C+12MB, usw. Für mich sieht das eher wie die intel-typische Marktsegmentierung aus, wo man dem Benutzer bloß keinen little core zuviel freischaltet für sein Geld.

 

[latiose88]

-Zitat entfernt-

Zum ersten Block abschnitt,ich habe einmal smt abgeschaltet ja das stimmt,dann sind es 16 Threads und dann das andere im Taksmanager da ja jeder Kern 2 Threads hat,habe ich ja bei 4 Kernen die echten Threads abgeschaltet.So das die 4 Kerne somit nur noch 50 % ausgelastet werden.Diese habe ich zum simulieren verwendet,da ich diese genau zum Zocken verwenden will.Das heißt das 4 Kerne,die jeweiligen Threads unterschiedliche aufgaben machen.Damit teilt sich wohl auch der CPU Cache auf.Das heißt die Simulierten Threads der 4 Kerne habe ich zum umwandeln verwendet,die anderen 4 Threads jeweils fürs zocken freigehalten.Das macht dann 24 + 4 Threads und das ergibt,na was wohl ,klar 28 Threads.Ich hoffe nun verstehst du was ich meinte.Und da verlor dabei die Software keine Leistung,im gegensatz zum Smt ganz abschalten.Ich weis zwar nicht was mir das sagt,aber es zeigt ja klar,das die Software nicht so gut skaliert wie ich gedacht hatte.Das ganze teilen sich somit die 2 Software.Weshalb dann pro Software am ende wohl so 14 Threads (was ja einen nicht vorhanden 7 Kerner entspricht),am ende nur noch übrig bleibt.
Was sagst du dazu ,kannst du mir sagen,wie das sein kann,das es so wenig Kerne sind die wo die SOftware nur dann davon profitiert?

Achja und das zweite.Beim der Umgewandelte aufnahme,da wird dann per media info mit somit 18 Threads angezeigt ,das was halt die software verwendet hatte.Beim 4 Kerner mit HT waren es 12 Threads gewesen.Das ist ja noch schlüssig,aber das es dann ab 10 Kerner schon immer 18 Threads angezeigt hatte.Ich bin davon imemr ausgegangen das es beim 10 kerner mit Ht ja eigentlich dann 25 oder gar 30 Threads wären.Allerdings wenn ich die Threadszahl in der Software erhöht hatte,da brach dann die Geschwindigkeit ein,seid dem lies ich es auf Auto.Es kommt allerdings immer nur 18 Threads am ende beim ergebnis raus. Was hat das denn zu bedeuten.Also die SOftware kann rein Theroretisch auf maximal 128 Threads manuell eingestellt werden.Sie nutzt das allerdings nicht aus.Wofür kann denn dann die Software soviele Threads denn dann rein Therotisch nutzen,wenn sie diese jedoch nie wirklich nutzen tut.Kann man das mir denn einer erklären.Ich verstehe es nicht.

 

[C.J.]

Siehe PN, wird sonst zu offtopic

 

[xexex]

Die Chance dass alle 8 großen Kerne gehen, aber die kleinen nicht ist sehr klein. Und wenn, dann werden nicht viele defekt sein.

Ich denke es geht hierbei aber nicht nur um Defekte, sondern auch um die Taktfreudigkeit dieser Kerne. Ich finde diese Segmentierung auch ziemlich seltsam, aber irgendwas wird sich Intel dabei schon gedacht haben und letztendlich wird auch bei AMD so ziemlich jedes Die noch verwurstet.

 

[Holt]

Typischer Sales-Dominierter Launch. Hier werden mal gefühlt alle technisch möglichen Varianten auf den Markt geworfen.

Was für ein Launch und wo wird hier was auf den Markt geworfen? Dies ist keine News zu einem Launch und auch in der News steht klar, dass die Eintragung in einer Liste (was Coreboot ist kannst du mal selbst ergooglen) nicht bedeuten muss, dass diese ganzen Varianten auch auf den Markt kommen. Es gibt hier also nur im Gerüchte und vor Alder Lake kommt noch eine andere Generation, vermutlich Rocket Lake, aber mich würde es auch nicht wundern, wenn es Tiger Lake wird.

Also einer hat zu mir mal gesagt wenn die CPU auf 100 % auslastung gehen würde,würde sie kaputt gehen.Stimmt allerdings nicht.

Klar stimmt das nicht, da hat dir jemand einen Bären aufgebunden. Wieso sollte eine CPU auch kaputt gehen, wenn sie keine Wartezyklen mehr einschieben müsste? Dies ergibt keinen Sinn. Es wird natürlich umso schwerer 100% CPU Last im Task Manager zu sehen, je mehr Kerne die CPU hat, da der Task Manager nur 100% anzeigt, wenn alle Kerne voll ausgelastet sind und selbst wenn die Software dies kann, gibt es bei mehr Kernen auch mehr Konflikte um RAM Zugriffe um diese Kerne auch mit Daten versorgen und damit auslasten zu können. Es geht aber nichts kaputt, wenn dies mal gelingt.

aber Sinn sehe ich nicht darin die Anzahl der kleinen Cores zu reduzieren. Was sollen dies Varianten?

Ehrlich gesagt frage ich mich was Big.little im Desktop überhaupt soll. Die Desktop CPUs sind doch im Idle schon sehr sparsam, auch da die Kerne die nicht genutzt werden eben keine Leistungsaufnahme haben, will man da noch ein Watt oder zwei sparen, die ein kleiner Kern weniger brauchen würde um einen leeren Windows Desktop zu verwalten? Die gehen doch bei der Leistungsaufnahme des restlichen Desktop Systems unter, man schau sie an wie sehr die Idle Leistungsaufgnahme von einen Board zum anderen schwankt, während es praktisch egal ist ob ein i3 oder i9 im Sockel steckt.

Bei den Lakefield macht das ganze ja Sinn, die sind extrem auf Energiesparen optimiert, daher haben sie die 4 kleinen Kerne und dann packt man noch einen großen dazu um auch eine ordentliche Singlethreadperformance zu ermöglichen. Aber was soll das im Desktop? Die großen Kerne passen sich bezüglich des Taktes doch schon heute sehr gut der geforderten Leistung an und haben entsprechend weniger Leistungsaufnahme wenn man nicht die volle Leistung braucht. Klar sind die kleinen Kerne im unteren Leistungsbereich etwas effizienter, aber lohnt es sich dafür den Platz auf dem Die zu verbrauchen?

 

[Nixdorf]

Ich frage mich, was das für AVX bei den Atom-Kernen (Gracemont?) wird. Die Atom-Kerne müssen es ja anbieten, damit die CPU den erweiterten Befehlssatz dem OS melden kann. Aber AVX-Einheiten sind groß und stromhungrig. Genau das, was Atom nicht sein soll. Spekulation: Könnte es sein, dass das VINO (Vector in Name only) ist? Also irgendwelche elend lahmen per Microcode simulierten Einheiten, die nur lange genug arbeiten können müssen, bis die CPU die Threads auf die schnellen Kerne umgeschaufelt hat.

Ergänzung (7. August 2020)

Ehrlich gesagt frage ich mich was Big.little im Desktop überhaupt soll.

Das hab ich mich auch gefragt. Das Switchen von Anwendungen zwischen den Kernen kostet ja "Schwuppdizität", und genau die mag man bei flotten Prozessoren. Es gibt aber einen Punkt, wo es was bringen könnte: Die schnellen Kerne könnte man komplett powergaten, und zum Zeitpunkt des Kontextwechsels sind die dann "kalt" und haben daher mehr thermisches Budget für etwas längeren Turbo. Das erscheint mir aber als homöopathischer Bonus, der den Aufwand nicht wert ist.

Ergänzung: Ach ja, und natürlich ist das dann eine "16-core CPU". Die Kerne sind natürlich auch für exzellentes Marketinggeschwurbel hilfreich.

 

[Fresh-D]

@xexex: Das meinte ich damit ich als ich das schrieb. Heute schon wird mit Taktraten geworben die vielleicht erreicht werden, dass wird mit big.LITTLE dadurch nur noch schlimmer.

Da kaufen dann alle, vor allen Dingen die welche sich gar nicht auskennen, noch mehr die Katze im Sack als es heutzutage schon mit den ganzen Boost-/Turbotaktraten der Fall ist.

 

[yummycandy]

Könnte es sein, dass das VINO (Vector in Name only) ist? Also irgendwelche elend lahmen per Microcode simulierten Einheiten, die nur lange genug arbeiten können müssen, bis die CPU die Threads auf die schnellen Kerne umgeschaufelt hat.

Gibt ja genug Subsets bei AVX, die werden schon so wenig nehmen, damit sie es gerade noch AVX nennen können. Siehe dem AVX-F Drama.

 

[hoxi]

Diese big/little-Implementierung von Intel dient doch nur dazu, um mit den 16 Kernen von AMD zumindest auf Marketing Slides gleichziehen zu können. So lange Intel seine Herstellungsprozesse nicht in den Griff bekommt, sehe ich schwarz für die Zukunft des Unternehmens.

 

[Holt]

Ich frage mich, was das für AVX bei den Atom-Kernen (Gracemont?) wird. Die Atom-Kerne müssen es ja anbieten, damit die CPU den erweiterten Befehlssatz dem OS melden kann.

Auf jeden Fall dürfte es wie bei Lakefield wohl kaum möglich sein ein Feature zu melden welches nicht beide Arten von Kernen können. Hier wird spekuliert das Alfer Lake-S kein AVX512 unterstützen wird, was aber wohl ein Rückschritt zum Vorgänger wäre und damit nicht so wahnsinnig wahrscheinlich.

Also irgendwelche elend lahmen per Microcode simulierten Einheiten, die nur lange genug arbeiten können müssen, bis die CPU die Threads auf die schnellen Kerne umgeschaufelt hat.

"Gracemont soll zumindest neueres AVX mitbringen", man kann ja auch 512 Bit in zwei Schritten auf 256 Bit breiten Einheiten berechnen, AMD hat es bis Zen2 bei 256 Bit Befehlen auch so gemacht, die liefen auch auf 128 Bit breiten Einheiten ab. Dies bringt dann zwar gegenüber Befehlen in der Breite der Einheiten keinen Performancegewinn, aber elend lahm ist es auch nicht. Wusstest Du übrigens das die Skylake-X/-SP zwei 256 Bit AVX Einheiten haben und daher die Modelle mit einer AVX-512 Einheit gegenüber den 256 Bit AVX2 Befehlen keinen Leistungsvorteil bringen?

Das Switchen von Anwendungen zwischen den Kernen kostet ja "Schwuppdizität", und genau die mag man bei flotten Prozessoren.

Eben, genau um diese Schwuppigkeit zu steigern, hat Intel mit Skylake SpeedShift eingeführt und bei Kaby Lake dann Speedshift 2:

AMD war ebenfalls schon gleich nach der Einführung der Turbotakt mit dem Phenom II für AM3 dabei die Geschwindigkeit der Taktanpassung zu optimieren und hat dafür schon bei AM3+ den Takt der Verbindung zum Spannungsregler deutlich gesteigert:

Deshalb waren AM3+ CPUs im Alltag in AM3 Boards auch so viel langsamer, außer man hat deren Takt im BIOS fixiert, dann spielte es keine Rolle ob sie in einem AM3 oder AM3+ Board saßen. AMD hing dann eine ganze Weile bei dem Thema hinterher, aber bei Zen2 sollen nun die Taktraten innerhalb (weniger als) einer ms angepasst werden können, keine Ahnung in welchem Umfang, aber es zeigt wie wichtig beide Hersteller dieses Thema nehmen, denn es ist für die Schwuppigkeit wichtig: Wenn eine hohe Last anliegt, dann muss die CPU den Takt möglichst schnell anheben, damit diese Last, die Alltag oft nur kurz anliegt, eben auch schnell abgearbeitet werden kann und danach soll der Takt zum Energiesparen möglichst schnell wieder gesenkt werden. Dies bringt (fast) keine Punkte in Benchmarks die länger Dauerlast anlegen wie z.B. Cinebench, macht aber im Alltag der meisten Anwender und auch in Spielen einen durchaus spürbaren Unterschied.

Auch deshalb habe ich ein Problem den Vorteil von BIG.little im Desktop zu erkennen, denn auch ich fürchte das man da einen Rückschritt machen wird. Aber vielleicht hat Intel da ja eine Lösung gefunden, man wird sich da überraschen müssen, denn ich kann mir kaum vorstellen, dass man diesen Aspekt plötzlich aus dem Auge verloren hat. Vielleicht sind die big und little Kerne ja viel stärker integriert als wir jetzt denken oder man schafft es die big Kerne ohne Last viel schneller auf Takt zu bringen und übergibt ihnen dann die Arbeit und ist am Ende trotzdem schneller als wenn man sie unter Last hochtakten müsste. Wer weiß schon was sie sich da ausgedacht haben, aber vergessen werden sie das Problem wohl kaum haben.

Die schnellen Kerne könnte man komplett powergaten, und zum Zeitpunkt des Kontextwechsels sind die dann "kalt" und haben daher mehr thermisches Budget für etwas längeren Turbo.

Silizium leitet die Wärme ganz gut und was TDP und Kühlung angeht, ist dies eher eine Sache für die OEM Rechner, die Retail Mainboard übertakten die CPUs schon in der Default Einstellung ganz gewaltig, selbst die mit H Chipsatz betreiben am liebsten alle Kerne ständig mit dem maximalen Multi, auch wenn der eigentlich nur für Singlethreadlasten ist. Die Enthusiasten schnallen da auch entsprechende Kühler drauf, die K Modelle werden ja schon gar nicht mehr mit einem Boxed Kühler ausgeliefert und drehen gerne noch mehr an der Taktschraube, daher halte ich dies für weniger wahrscheinlich. Zumal die ganzen OEM Kisten und deren Kunden sowieso keinen besonderen Wert auf die maximale Höchstleistung legen, sonst würden sie sich ja nicht solche OEM Kisten holen.

Ach ja, und natürlich ist das dann eine "16-core CPU". Die Kerne sind natürlich auch für exzellentes Marketinggeschwurbel hilfreich.

Dies könnte natürlich sein, wobei es dann aber schnell zu einer Klage kommen könnte, wenn nicht alle 16 Kerne gleichzeitig nutzbar sind. Dies ist nämlich was ein Kunde eines 16 Kerners bisher gewohnt ist und wenn das Marketing da nicht ganz vorsichtig ist, bekommen sie genau wie AMD damals mit den Bulldozer Modulen eine Sammelklage. Damals hatte AMD die 4 Moduler als 8 Kerner, ich meine sogar als 8 native Kerne angepriesen und weil der normale Kunden unter einem Kern eben mehr verstand als eine Hälfte des Moduls geboten hat, endete es in einem Vergleich. Nur hätte AMD diesen Vergleich ja nie geschlossen, wenn sie ihrer Sache sicher gewesen wären und kein negatives Urteil gefürchtet hätten.

Aber vielleicht bringt Intel ja auch da eine Lösung um die big und die little Kerne gemeinsam betreiben zu können, mit entsprechenden Anpassungen beim Task Scheduler des OS sollte dies eigentlich machbar sein. Microsoft hat da ja schon für Zen und seine CCX Architektur und dann für TR mit seinen zwei und später 4 Dies einiges gemacht, die werden Intel da kaum im Wege stehen. Natürlich hätten dann nicht alle Kerne die gleiche Performance (wohl schon wegen der Taktraten) wie es bisher bei Multithreadinganwendungen üblich ist, aber schon bei den RYZEN 3000 12 und 16 Kernern taten nicht immer alle Kerne unter Last gleich hoch, weil nicht beide Dies die gleichen Eigenschaften haben. Klar wäre es bei BIG.little noch extremer, aber im Prinzip ist der Drops schon einmal gelutscht und wäre nur größer.

Es wäre dann auch ein echter 16 Kerner und damit würde BIG.little auch im Desktop wirklich Sinn machen, weil man eben auch die Multithreadperformance damit deutlich steigern könnte, zumindest bei denen mit genug Little Kernen, bei 8+2 wäre dies wohl weniger der Fall.

So lange Intel seine Herstellungsprozesse nicht in den Griff bekommt, sehe ich schwarz für die Zukunft des Unternehmens.

Das würde ich nicht sagen, die Probleme bei der Fertigung sind zwar ein Klotz am Bein, aber weder TSMC noch GF haben damals die 20nm in den Griff bekommen und somit hingen AMD und NVidia lange bei 28nm fest und waren gezwungen andere Lösungen zu finden um die Performance (vor allem) der GPUs zu steigern, was beide auch geschafft haben. Schau Dir die Leistung der ersten 28nm GPUs an und die der letzten in 28nm gefertigten GPUs, da hat sich viel getan, was man sonst einfach mit den Fortschritten bei der Fertigung hätte erschlagen können, ohne so viel Hirnschmalz reinzustecken. Aber von dem Hirnschmalz hat man dann auch profitiert als der Knoten bei der Fertigung endlich geplatzt war. Daher halte ich es für verfrüht Intel abzuschreiben, denn man sollte die Kreativität der Entwickler nicht unterschätzen, wenn ihnen Hindernisse in den Weg gelegt werden, finden sie oft die erstaunlichsten Lösungen auf die sie sonst nie gekommen wären. Die Geschichte ist voll von Beispielen dafür!

Intel abzuschreiben nur weil es bei der Fertigung klemmt, ist für die AMD Fanboys (egal wie sehr sie es hassen so geoutet zu werden) noch zu früh. Solange AMD nicht auch bei der Gamingperformance vorne liegt, denn dafür zahlen diejenigen sie sich das leisten können und wollen einiges, ist Intel im Desktop nicht geschlagen und wird Aufpreise für CPUs verlangen können, die bei Cinebench billigeren AMD Modellen unterlegen sind.

 

[Haldi]

Der einzige Ort wo ich mir Big.LITTLE wirklich wünsche wäre im NAS. So ein 35W CPU die im normalen Betrieb mit Webservice/Datei Server und par docker Container nicht über 3W braucht.

 

[Nixdorf]

Gibt ja genug Subsets bei AVX, die werden schon so wenig nehmen, damit sie es gerade noch AVX nennen können.

Das erklärt @Holt nochmal:

Auf jeden Fall dürfte es wie bei Lakefield wohl kaum möglich sein ein Feature zu melden welches nicht beide Arten von Kernen können.

Wenn die CPU einen Befehl anbieten will, dann müssen ihn (momentan) alle Kerne der CPU können, weil das Software-Ökosystem aktuell keine Möglichkeit vorsieht, ein Binary gezwungen auf der einen Sorte Kerne auszuführen, weil da Befehle drin sind, die die anderen Kerne nicht können. Somit müssen die Atom-Kerne zumindest alle AVX-Befehle irgendwie ausführen können, die auch die Core-Kerne anbieten. Es muss nicht schnell sein, es kann zum Beispiel mit den ebenfalls von @Holt genannten halbierten Einheiten umgesetzt werden.

Ich habe mich mit dem Platzbedarf übrigens vertan. Ganz so schlimm wie ich es im Kopf hatte, ist der Platzbedarf für AVX nicht.

Eben, genau um diese Schwuppigkeit zu steigern, hat Intel mit Skylake SpeedShift eingeführt und bei Kaby Lake dann Speedshift 2

Ja eben. Man hat da extra Arbeit investiert, damit die Reaktionszeit bis zum vollen Takt schneller wird. Und jetzt kommt wieder Latenz für das Umschaufeln des Kontexts auf den schnellen Kern dazu. Jedenfalls will man Code möglichst schnell mit der höchsten Leistung der gesamten CPU ausführen können, und der zusätzliche Arbeitsschritt bremst das aus. Daher ergibt big.LITTLE bei den Desktop-Chips keinen Sinn.

Dies könnte natürlich sein, wobei es dann aber schnell zu einer Klage kommen könnte

Das stumpfe Schwert von Klagen mit Portokasse-Strafen hat das Intel-Marketing noch nie von irgendwelchen dunklen Praktiken abgehalten. Außerdem...

Aber vielleicht bringt Intel ja auch da eine Lösung um die big und die little Kerne gemeinsam betreiben zu können

...macht Intel das doch beim Lakefield auch schon.

 

[xexex]

Wenn die CPU einen Befehl anbieten will, dann müssen ihn (momentan) alle Kerne der CPU können, weil das Software-Ökosystem aktuell keine Möglichkeit vorsieht, ein Binary gezwungen auf der einen Sorte Kerne auszuführen,

Das ist aber meines Wissens eine Behauptung, für die ich jedoch im Netz auf Anhieb keinen Beweis finde. Es ist ja jetzt schon so, dass manche CPUs nur einer und andere zwei AVX512 Einheiten bieten, ich wüsste nicht wieso es ein Problem sein sollte auch Kerne ohne eine solche Einheit einzusetzen.

Hier wird es auch noch besser erklärt.

This is the first implementation to incorporate AVX-512, a 512-bit SIMD x86 instruction set extension. AVX-512 operations can take place on every port. For 512-bit wide FMA SIMD operations, Intel introduced two different mechanisms ways:

In the simple implementation, the variants used in the entry-level and mid-range Xeon servers, AVX-512 fuses Port 0 and Port 1 to form a 512-bit FMA unit. Since those two ports are 256-wide, an AVX-512 option that is dispatched by the scheduler to port 0 will execute on both ports. Note that unrelated operations can still execute in parallel. For example, an AVX-512 operation and an Int ALU operation may execute in parallel - the AVX-512 is dispatched on port 0 and use the AVX unit on port 1 as well and the Int ALU operation will execute independently in parallel on port 1.
https://en.wikichip.org/wiki/intel/...lake_(server)#Scheduler_.26_512-SIMD_addition

 

[Nixdorf]

Es ist ja jetzt schon so, dass manche CPUs nur einer und andere zwei AVX512 Einheiten bieten

Es geht nicht darum, was da für Hardwareeinheiten verbaut sind. Es geht darum, welchen Befehlssatz die CPU anbietet. Ob nun eine oder zwei Einheiten, in beiden Fällen wird Support für AVX512-Instruktionen gemeldet.

Bei Ryzen vor Zen2 war es auch so, dass er zwar nur 128bit breite AVX-Einheiten hatte und AVX2 in halber Geschwindigkeit bearbeitet wurde. Entscheidend ist, dass der Support für die AVX2-Instruktionen gemeldet wird und diese bearbeitet werden können.

Will Intel bei big.LITTLE die Unterstützung von AVX-512 melden, dann muss die CPU entsprechende Instruktionen in jeder Situation bearbeiten können. Also auch dann, wenn ein Thread gerade auf einem Atom-Kern läuft. Bei Lakefield wird aus genau diesem Grund keinerlei AVX-Support gemeldet: Die Atom-Tremont-Kerne dort haben die Instruktionen nicht, also wird AVX als nicht unterstützt gemeldet, obwohl der eine Core-Sunny-Cove-Kern es durchaus unterstützt. Das Silizium für dessen AVX-Einheit liegt brach.

 

[Holt]

Es ist ja jetzt schon so, dass manche CPUs nur einer und andere zwei AVX512 Einheiten bieten, ich wüsste nicht wieso es ein Problem sein sollte auch Kerne ohne eine solche Einheit einzusetzen.

Wie Nixdorf schon schreib, braucht Du wenigstens eine Einheit die die Befehle verarbeiten kann, sonst wird das nicht. Das ist als wenn Du in eine Copyshop gehst und nach einer Farbkopie fragst, ob der einen Farbkopierer hat oder zwei ist egal, aber wenn er keinen hat, kann er auch keine farbige Kopie machen und daher auch nicht anbieten. Die einzige Möglichkeit wäre, wenn nebenan ein anderer Shop einen hat den Mitarbeiter loszuschicken um sie dort machen zu lassen. Dies würde aber bei BIG.little bedeuten, dass die CPU die Arbeit an einen anderen Kern abgibt als der auf dem das Betriebssystem den Thread laufen lässt, sobald eine solche Instruktion kommt. Ob sowas technisch sinnvoll machbar ist, kann ich nicht beurteilen, es wäre zumindest Neuland und dem Betriebssystem die bisher vorhandene Kontroller darüber entziehen auf welchem Kern es einen Thread ausführt.

 

[smalM]

Dies würde aber bei BIG.little bedeuten, dass die CPU die Arbeit an einen anderen Kern abgibt als der auf dem das Betriebssystem den Thread laufen lässt, sobald eine solche Instruktion kommt.

Wenn der Threadwechsel erst erfolgen würde, weil der kleine Core beim Auftauchen eines AVX-Ops eine Exception schmeißt, dann wäre das fatal, die Performance unterirdisch. Im Prinzip müßte der der Scheduler von jedem Thread bereits im Voraus wissen, daß er auf einem kleinen Core nicht lauffähig ist, was völlig utopisch ist.

Zum Glück für Intel ist das Fehlen von AVX in den kleinen Cores überhaupt kein Problem, der rückwärtsgewandte Kompatibiltätsfetisch in der Wintel-Welt sorgt dafür.

 

[Holt]

Nun kennen wir des Rätzels Lösung: Intel-CPU-Roadmap: Alder Lake ist offizieller Nachfolger von Lakefield. Damit macht das Thema BIG.little dann auch wieder Sinn und Alder Lake wird nicht die (Nach)Nachfolge von Comet Lake im Desktop antreten. Wieder einmal waren die Gerüchte von ach so informierten Quellen also komplett falsch, Fakenews, Clickbaiting, ...

 

[latiose88]

Prozesse, die einen Kern nicht voll auslasten, kann man sicherlich ohne Probleme auf einen kleinen Kern verschieben. Das Problem ist halt wie du schon sagst, dass du bei einer starken MT-Last trotz 100% Auslastung lieber (auch) auf den kleinen Kernen bleiben willst, weil das in der Regel keine echtzeitkritischen Anwendungen sind und die kleinen Kerne durch die höhere Effizienz schneller fertig sind als die großen bei gleichem Verbrauch. Wobei das bei den hier beschriebenen Modellen wahrscheinlich eh nicht viel ausmacht. Der 8+8-Kerner soll angeblich mit 125-150W TDP kommen in 10nm. Da sollte also genug Ressourcen für alle Kerne gleichzeitig vorhanden sein. Interessant ist eher ein Verhältnis von 1:4 (big vs little) wie bei Lakefield. Da geht wirklich die Leistung nach unten, wenn die großen Kerne den Kleinen den Strom klauen.



Ich glaube dass damit eine andere Art von Auslastung gemeint ist. Mikrochips besitzen heute eine große Menge von "dark silicon", d.h. zu einem beliebigem Zeitpunkt ist der größte Teil des Chips aus, weil er nichts zu tun hat. Das gilt auch für einen 10900K, der 250W wegheizt. 100% Auslastung auf Transistorebene würden also eine solche CPU zum schmelzen bringen. Diese Auslastung ist aber nahezu unmöglich zu bestimmen und eigentlich ist es auch nicht beabsichtigt auf 100% zu kommen. Die Transistoren werden zwar immer kleiner, d.h. man kriegt immer mehr Schaltlogik auf der selben Fläche unter, aber der Verbrauch sinkt nicht im gleichen Maße, weswegen zwangsläufig mehr Teile davon inaktiv bleiben (es sind natürlich nicht immer die selben Teile inaktiv, sonst könnte man sie ja einfach weglassen), damit die Wärmedichte nicht steigt.

100% Auslastung im Taskmanager heißt übrigens nur, dass der Kern die Aufgabe, an der er gerade arbeitet, nicht schneller erledigen kann, d.h. er trödelt nicht, aber es müssen bei weitem nicht alle Teile des Kerns ausgelastet sein. Wenn du ein Programm startest, das nur Integer-Berechnungen macht und in den L1-Cache passt, ist die Auslastung der Fließkomma-Einheit und des L2-Caches natürlich 0%, weil sie für das Programm nicht benötigt werden. Ein Programm so zu schreiben, dass wirklich alles im Kern arbeitet, ist schwierig. Tools wie Prime95 versuchen das und schaffen es in der Regel auch eine CPU bei Takt X deutlich heißer zu bekommen als eine "reale" Anwendung.



Diese Rechnung verstehe ich nicht. Wenn der 18-Kerner auf 80% Auslastung bei einem perfekt parallelisierten Programm kommt, dann ist Arbeit für 14,4 Kerne da. Der 16-Kerner müsste dann bei 90% liegen und alles mit <=14 Kernen bei 100%. Ist dies bspw. bei 12 Kernen trotzdem nicht der Fall, dann beinhaltet das Programm vermutlich Teile, die nicht vollständig parallelisiert sind. Deswegen erreicht keine CPU mit mehr als einem Kern dort 100%, denn der serielle Teil muss ja irgendwann abgearbeitet werden.

Ob 8+8 schneller als 12+0 ist, kann man überhaupt nicht sagen, wenn man nicht weiß wie schnell genau die kleinen Kerne sind im Verhältnis zu den großen. Intel wird das sicher nicht aus Spaß machen, also kann man davon ausgehen, dass big+little langfristig besser in ihre Strategie passen. Imho ist es so, dass die meisten Anwendungen, die viel Singlethread-Leistung brauchen, sich mit 6-8 Kernen zufrieden geben. Alles was darüber hinausgeht, ist leicht parallelisierbar, d.h. man kann es theoretisch auch auf 64 Kernen rechnen. Also verbaut man in den CPUs zwei Sorten Kerne: Kleine und super effiziente Kerne, damit man möglichst viele davon in den Chip bekommt, und große, die nur auf maximale Singlethread-Leistung getrimmt sind und wo die Effizienz auch grottenschlecht sein darf.

Danke für die Info,gillt das dann auch dann wenn es sich um 16 mit smt oder gar 18 Kerner mit HT ist.
Also bei 10 Kerner wie dem i7 6950x habe ich noch 100 % auslastung gehabt,beim 12 Kerner wie dem i9 7920x hatte ich auch 100 % noch gehabt.Beim i9 9980xe ja dann auf einmal nicht mehr und beim Ryzen 9 3950x habe ich ebenso keine 100 % auslastung.Das heißt es gillt dann da das was du so geschrieben hast,das ein gewisser Teil dann nicht mehr Parallisiert werden kann nicht wahr? Kann man also da schon von einer Grenze sprechen?
Also bei einem 14 Kerner habe ich es allerdings noch garnicht probiert,aber denke mal das dies auch noch in Richtung 100 % auslastung sein wird.Was sagst du denn zu dem ganzen dann?