Funktioniert big.LITTLE? [Archiv]

lumines

2020-07-17, 15:43:38

Hi
gibt es eigentlich tests, wo eine big little multicore architektur tatsächlich funktioniert?

Was meinst du damit? Gibt es Beispiele, wo es nicht funktioniert?

Für was gibt es 4 kleine cores? werden die jemals ausgelastet?

Die kleinen Cores verbrauchen praktisch nichts und deshalb können die Hintergrundaufgaben abarbeiten, für die man die großen Cores erst gar nicht aktivieren will. Stell dir ein Smartphone vor, das im Hintergrund den lokalen Cache für die Avatare in einer Messaging-App aktualisiert.

Die kleinen Cores sind meistens auch von der Transistorzahl her verschwindend klein. Ob man zwei oder vier verbaut, macht da nicht so einen großen Unterschied. Im besten Fall kann man wahrscheinlich mit mehreren kleinen Kernen die Powerstates auch noch niedriger halten.

Es ist grundsätzlich fast immer stromsparender "in die Breite" zu gehen anstatt weniger Cores zu nehmen, die höher takten, wenn es irgendwie möglich ist. Der Sinn ist auch nicht die kleinen Cores pauschal möglichst stark auszulasten. Die kleinen Cores sind keine Wunderkerne, sondern dazu gedacht bei bestimmten Workloads die großen Kerne nicht unnötig zu "wecken", wenn es sich vermeiden lässt.

=Floi=

2020-07-17, 16:03:00

Funktioniert das überhapt richtig gut?

N0Thing

2020-07-17, 16:07:57

Hi
gibt es eigentlich tests, wo eine big little multicore architektur tatsächlich funktioniert?
Für was gibt es 4 kleine cores? werden die jemals ausgelastet?

Golem hat die neuen Intel-CPUs getestet: https://www.golem.de/news/core-i5-l16g7-lakefield-im-test-intels-x86-hybrid-cpu-analysiert-2007-149385.html

Rooter

2020-07-17, 16:10:30

Da es kleine Cores sind, werden die sicher ausgelastet. ;)

Mich mich würde mehr interessieren:
Wie entscheidet das OS was auf einem kleinen und was auf einen großen Core läuft?
Und, das weitergedacht: Kann eine App für ihre Threads bestimmen, ob sie auf einem kleinen oder großen Core laufen sollen?
Laufen nicht zeitkritische Hintergrundaufgaben immer auf kleinen Cores?

MfG
Rooter

PatkIllA

2020-07-17, 16:27:47

Mich mich würde mehr interessieren:
Wie entscheidet das OS was auf einem kleinen und was auf einen großen Core läuft?
Und, das weitergedacht: Kann eine App für ihre Threads bestimmen, ob sie auf einem kleinen oder großen Core laufen sollen?
Laufen nicht zeitkritische Hintergrundaufgaben immer auf kleinen Cores?
Das war zumindest anfangs mal transparent für das OS, dass nur noch die Stromsparstufe setzte und die Hardware hat das dann je nach Auslastung auf den Kernen ausgeführt.

Gast

2020-07-17, 16:54:06

Was heißt es "funktioniert"?

Der Sinn des Ganzen ist eben, dass je nach Betriebspunkt mal die kleinen mal die großen Kerne effizienter sind.

lumines

2020-07-17, 17:01:11

Funktioniert das überhapt richtig gut?

Es gab in den Anfängen Probleme mit der Verteilung, aber die hat man schon vor vielen Jahren behoben.

Wie entscheidet das OS was auf einem kleinen und was auf einen großen Core läuft?

Mittlerweile entscheidet das OS das glaube ich gar nicht mehr.

Und, das weitergedacht: Kann eine App für ihre Threads bestimmen, ob sie auf einem kleinen oder großen Core laufen sollen?

Würde mich ehrlich gesagt wundern. Gerade auf mobilen Plattformen haben Apps nur einen sehr geringen Einfluss auf so etwas.

Rooter

2020-07-17, 18:31:06

Mittlerweile entscheidet das OS das glaube ich gar nicht mehr.Wer dann? Das SoC?

MfG
Rooter

bnoob

2020-07-17, 19:34:48

Normalerweise bei aktuellen Implementierungen ja, wobei Linux seit 5.0 einen sogenannten Energy Aware Scheduler hat, also das theoretisch auch selbst machen kann.

Wie GENAU das bei Intel gelöst ist geben die Leaks aber noch nicht her.

Und da wir das im mobile-Bereich schon fast 10 Jahre haben ist das Konzept an sich mittlerweile auch mal ausgereift, die Frage ob es *funktioniert* stellt sich überhaupt nicht mehr, spätestens seit Apple das mit dem A11 in eigenem Silicon benutzt.

CD-LABS

2020-07-19, 08:14:58

Funktioniert das überhapt richtig gut?
Ich kenne keinen Test, indem es für die gängigen, weit verbreiteten ARM-Vertreter jeweils sauber überprüft wurde...
...also indem künstlich die großen und künstlich die kleinen Kerne belastet und deren Leistungsaufnahme und Performance gemessen wurde.

Argo Zero

2020-07-19, 10:01:49

Werden wir im nächsten Mac sehen mit ARM SoC.
Ich gehe schwer davon aus, dass es lastabhängig ist und weitere Cores dazu geschaltet werden.

Gast

2020-07-19, 11:31:09

Mittlerweile entscheidet das OS das glaube ich gar nicht mehr.

In aktuellen Implementierungen entscheidet nur mehr der OS Scheduler.

Am Anfang war noch Cluster Switching üblich, bei dem jeweils ein Cluster aus beispielweise 4 großen mit 4 kleinen Kernen gepaart wurden. Das OS setzt hier nur die Energiezustände und die Hardware entscheidet selbst ob es auf den großen oder kleinen Kernen ausgeführt wird.
Das OS sieht bei dieser Hardware auch nur 4 Kerne.

Die nächste Variante ist dann CPU migration, das funktioniert ähnlich, allerdings wird jede große CPU mit einer kleinen gepaart und diese können individuell geswitcht werden.
Das OS sieht hier auch nur 4 Kerne, bei 4+4 physischen Kernen, der Vorteil ist allerdings wenn nur für 1 Thread hohe Leistung benötigt wird muss auch nur 1 Kernpaar auf den Leistungsfähigen Kern geswitcht werden, während der Rest auf den kleinen Kernen bleiben kann.

Tegra X1 funktioniert beispielsweise nach dem Prinzip um mal einen SoC zu erwähnen der auch noch in aktueller Hardware verwendet wird.

Dann gibt es noch die Variante mit "Schattenkernen", wie sie in den alten Tegras verwendet wurden, teilweise sogar noch vor big.LITTLE. Da gab es 4 Kerne + einen weiteren mit anderem Transistordesign um höhere Taktraten zu ermöglichen.
Das OS sieht hier auch nur die 4 Kerne und die Hardware entscheidet selbst, wann etwas auf dem 5. unsichtbaren Kern ausgeführt wird.

Praktisch alles neue verwendet aber global task scheduling.
Bei der Variante sieht das OS alle vorhandenen Kerne und der OS-Scheduler vergibt die Tasks auf die einzelnen Kerne.
Damit ist man natürlich sehr viel flexibler und es können prinzipiell auch alle Kerne gleichzeitig verwendet werden.
Wobei der Gerätehersteller hier natürlich sehr flexibel ist in der Balance zwischen Leistung und Stromverbrauch und in der Entscheidung was wann auf welchen Kernen ausgeführt werden kann.

Was wir hier in letzter Zeit auch immer öfter sehen sind Architekturen mit mehr als nur 2 unterschiedlichen Kernstufen bzw. auch mit unterschiedlicher Anzahl an Kernen je Leistungsstufe, was ohne GTS eigentlich kaum vernünftig möglich wäre.

lumines

2020-07-19, 12:03:17

Ich kenne keinen Test, indem es für die gängigen, weit verbreiteten ARM-Vertreter jeweils sauber überprüft wurde...
...also indem künstlich die großen und künstlich die kleinen Kerne belastet und deren Leistungsaufnahme und Performance gemessen wurde.

Mittlerweile kann man das nicht mehr so fein justieren, aber man kennt die "kleinen" Kerne aus anderen Geräten. Viele Midrange- und Low-End-Smartphones nutzen keine "big"-Kerne und nur einen Haufen "little"-Kerne. Daraus kann man schon die meisten Schlüsse ziehen, was die Performance der einzelnen Kerne angeht.

Werden wir im nächsten Mac sehen mit ARM SoC.
Ich gehe schwer davon aus, dass es lastabhängig ist und weitere Cores dazu geschaltet werden.

Wäre auch seltsam, wenn die ARM-Macs vollkommen anders funktionieren würden als die bestehenden ARM-Geräte von Apple.

CD-LABS

2020-07-19, 12:38:57

Ich gehe auch fest davon aus, dass es zumindest bei Apple gut (also sowohl von Performance- als auch vom Effizienzgewinn her) funktioniert, Lakefield hingegen sah (wenig überraschend; Wintel halt...) eher noch mäßig aus.

So oder so braucht es für den Desktop-Markt in meinen Augen eher big.LITTLE.huge(so genau lässt sich das coole Namensschema nicht übertragen) Also zwei Kerne für Legacy-Software, einige Kerne für moderne Performance-Software, wenige für Quasi-Idle-Software.
Das würde insbesondere endlich auch mal einiges an Performancegewinn für LastGen-Titel/ Software mit SingleCoreFokus bringen.
Edit: huge meint drastisch breitere Kerne als alle, die bislang bei big.Nothing im Desktop vorhanden sind.

lumines

2020-07-19, 13:05:38

So oder so braucht es für den Desktop-Markt in meinen Augen eher big.LITTLE.HuGe (so genau lässt sich das coole Namensschema nicht übertragen) Also zwei Kerne für Legacy-Software, einige Kerne für moderne Performance-Software, wenige für Quasi-Idle-Software.

Am Desktop wird man wahrscheinlich nicht so sehr den Bedarf nach einer big.LITTLE-Architektur haben. Ob ich im Idle 1 Watt mehr oder weniger verbrauche, interessiert mich am Desktop jetzt nicht so sehr.

Das würde insbesondere endlich auch mal einiges an Performancegewinn für LastGen-Titel/ Software mit SingleCoreFokus bringen.

Genau das macht man doch schon immer am Desktop, oder nicht? Desktops sind ja beim thermischen Budget und der Leistungsaufnahme praktisch unlimitiert. Ich bin mir jedenfalls ziemlich sicher, dass man beim Design der High-End-Desktop-CPUs keine Limitierungen eines Smartphone-Akkus berücksichtigt.

PacmanX100

2020-07-19, 13:06:59

Also zwei Kerne für Legacy-Software, einige Kerne für moderne Performance-Software, wenige für Quasi-Idle-Software.
Das würde insbesondere endlich auch mal einiges an Performancegewinn für LastGen-Titel/ Software mit SingleCoreFokus bringen.

Ich glaube von dem gedanken kannst du dich verabschieden. ;)
Dafür müssten die ja über 5.2 GHz kommen um besser zu sein als heutige. Und damit kommen sie leider bereits an die Fertigungsgrenze.
Das schaffen die ja auch mit Turbomode kaum bis gar nicht.

Ich finde das Konzept im Desktop absolut verschwendet da es da kein Stromproblem geben wird. Im Notebook könnte es noch Sinn machen aber da sind moderne Prozessoren schon so sparsam das es keinen Unterschied machen wird da andere Komponenten mehr brauchen.

Das Konzept ist natürlich nicht verkehrt für sagen wir mal 96, 128, 256 Kerne, die brauchen nicht alle Volllast laufen. Aber die Stromsparmechanismen sind schon so ausgereift das ja sogar bereits Einheiten oder sogar Cachteile abgeschaltet wurden. Was braucht eine moderne CPU im Idlebetrieb? Selten mehr als 5W. Was willst daran noch sparen? Und Wozu?! Turbomode finde ich dagegen recht sinvoll, das sollte so laufen das jeder Kern regelbar ist durch Benutzer oder Mainboard.

BlacKi

2020-07-19, 13:38:10

Golem hat die neuen Intel-CPUs getestet: https://www.golem.de/news/core-i5-l16g7-lakefield-im-test-intels-x86-hybrid-cpu-analysiert-2007-149385.html
das ist schon interessant. 1 SuNnyCove kern ist so groß wie 4 TremoNT kerne. 1SNC dabei aber nur fast halb so schnell als 4 TNT in cinebench. das wäre eine performance verdoppelung per watt. allerdings nicht pro mm².

wenn die kerne nicht gleichzeitig arbeiten ist es im prinzip siliziumverschwendung und damit rausgeschmissenes geld.

allerdings sehe ich im desktop dafür verwendung. aber einen alderlake mit 8+8 ist halt kein reiner 16kerner der alten schule. die einordnung muss damit in zukunft rein auf die performance zu sehen sein, eine einordnung nach kernen kann man nichtmehr vornehmen.

wenn die goldencove nochmals größer werden als die sunnycove kerne, dann nehmen die kleinen 8 kerne praktisch keine fläche ein. eher soviel wie 1,5 SNC kerne.

ich halte den schritt für die richtige richtung, denn wenn ich mit die lasten auf meinem 6 kerner ansehe, würde mir wohl auch ein 4+4 core setup derzeit genügen.

ich bin gespannt, wieviel wir für diesen 8 +1,5(flächenverhältnis) kerner dann zahlen müssen.

CD-LABS

2020-07-19, 14:00:32

Am Desktop wird man wahrscheinlich nicht so sehr den Bedarf nach einer big.LITTLE-Architektur haben. Ob ich im Idle 1 Watt mehr oder weniger verbrauche, interessiert mich am Desktop jetzt nicht so sehr.
(...)
Natürlich interessieren die +-1W aktuell nicht, denn wir sind ja gerade bei etwa 35W, die Desktops ohnehin unnötig verballern. Ich hoffe sehr, dass das bei den nächsten Sockeln (also insbesondere AM5) von vorneherein wegoptimiert wird.
(...)Genau das macht man doch schon immer am Desktop, oder nicht? Desktops sind ja beim thermischen Budget und der Leistungsaufnahme praktisch unlimitiert. Ich bin mir jedenfalls ziemlich sicher, dass man beim Design der High-End-Desktop-CPUs keine Limitierungen eines Smartphone-Akkus berücksichtigt.
Die Boost-Algorithmen erfüllen meiner Erfahrung nach in der Praxis nicht die theoretisch gestellten Anforderungen an einen guten Boost-Algorithmus. Mein Musterbeispiel dafür ist die auf etwa zwei Threads optimierte Drakensang-Reihe (klar, bei meinem Nick, oder?), denn dort steigt Performance sowohl, wenn ich SMT, als auch wenn ich vier Kerne meines 2700ers deaktiviere. (unterm Strich gewinne ich etwa 20%, ist aber nicht sauber durchgemessen) Wünsche mir immer, dass mal eine Redaktion die Titel nochmal durchbenched, aber leider wurden die Wünsche bislang nicht erhört... :(

So oder so ist das Konzept der großen Kerne aber ein anderes: Wirklich breit gebaute Kerne, womöglich kombiniert mit einem exklusiven Cache direkt neben ihnen. Muss halt noch sichergestellt werden, dass sie unterm Strich (trotz wahrscheinlich geringerem Takt) dann auch wirklich schneller sind.

lumines

2020-07-19, 15:52:34

Die Boost-Algorithmen erfüllen meiner Erfahrung nach in der Praxis nicht die theoretisch gestellten Anforderungen an einen guten Boost-Algorithmus. Mein Musterbeispiel dafür ist die auf etwa zwei Threads optimierte Drakensang-Reihe (klar, bei meinem Nick, oder?), denn dort steigt Performance sowohl, wenn ich SMT, als auch wenn ich vier Kerne meines 2700ers deaktiviere.

Na ja, in so einem Fall würdest du gerade nicht von noch mehr Kernen profitieren. Du hast ja schon sechs "Huge"-Kerne.

CD-LABS

2020-07-19, 15:59:38

Na ja, in so einem Fall würdest du gerade nicht von noch mehr Kernen profitieren. Du hast ja schon sechs "Huge"-Kerne.
Sorry, ich dachte, ich hätte das klar genug ausgedrückt: Die aktuellen Kerne sind die big-Kerne, die huge -Kerne meinen fettere Kerne.

lumines

2020-07-19, 16:20:19

Sorry, ich dachte, ich hätte das klar genug ausgedrückt: Die aktuellen Kerne sind die big-Kerne, die huge -Kerne meinen fettere Kerne.

Mir ist schon klar, was du meinst, aber nur weil du deine Kerne gedanklich umklassifizierst, ändert das ja nichts an der Hardware. Alle High-End-Desktop-CPUs sind "Huge". Deine CPU ist rein thermisch limitiert.

Das ganze big.LITTLE-Konzept ergibt ja nur Sinn, wenn man nach unten skalieren will.

CD-LABS

2020-07-19, 16:34:56

Mir ist schon klar, was du meinst, aber nur weil du deine Kerne gedanklich umklassifizierst, ändert das ja nichts an der Hardware. Alle High-End-Desktop-CPUs sind "Huge". Deine CPU ist rein thermisch limitiert.
(...)
Anders gesagt, du bist überzeugt, dass sich durch Opfern von Flächeneffizienz nicht mehr signifikante Mehrperformance erreichen lässt? Also ich denke da an so was wie bei gleicher Leistungsaufnahme Flächenverbrauch von vier Kernen, praktischer Performancegewinn von >10%---sowas hältst du für nicht möglich?
Sprich, dass die aktuell verwendeten Kerne sich schon ziemlich nah an dem für die jeweiligen Hersteller erreichbarem Limit befinden.

Edit: Es widerspricht auch dem, was ich zu IBM Z vs. IBM Power mitbekommen habe---mit Z flächenineffizient, aber gut für Legacysoftware vs. Power flächeneffizient und gut für moderne Software.

lumines

2020-07-19, 17:23:10

Anders gesagt, du bist überzeugt, dass sich durch Opfern von Flächeneffizienz nicht mehr signifikante Mehrperformance erreichen lässt? Also ich denke da an so was wie bei gleicher Leistungsaufnahme Flächenverbrauch von vier Kernen, praktischer Performancegewinn von >10%---sowas hältst du für nicht möglich?
Sprich, dass die aktuell verwendeten Kerne sich schon ziemlich nah an dem für die jeweiligen Hersteller erreichbarem Limit befinden.

Man kann den Takt der Kerne eben nicht unbegrenzt nach oben prügeln und in vielen Fällen gehst du damit auch andere Kompromisse ein. Veraltete Videospielengines sind z.B. sicher nicht der Anwendungsfall, auf den Intel optimieren wird.

Edit: Es widerspricht auch dem, was ich zu IBM Z vs. IBM Power mitbekommen habe---mit Z flächenineffizient, aber gut für Legacysoftware vs. Power flächeneffizient und gut für moderne Software.

Na ja, Legacy heißt bei IBM Mainframe-Anwendungen. Das sind schon fundamental andere Architekturen als x86 oder ARM. Ich würde auch nicht zu viel auf das IBM-Marketing geben.

Gast

2020-07-19, 19:28:57

das ist schon interessant. 1 SuNnyCove kern ist so groß wie 4 TremoNT kerne. 1SNC dabei aber nur fast halb so schnell als 4 TNT in cinebench. das wäre eine performance verdoppelung per watt. allerdings nicht pro mm².

Man muss aber beachten, dass der SNC Kern entgegen Intels Aussagen die AVX512 Einheit in Hardware hat die er nicht verwenden kann, und die ist so groß dass man sie im DIE-Shot sehen kann.

Wenn er die AVX512-Einheit verwenden könnte, oder diese nicht vorhanden wäre, sehe es im Bezug auf Leistung/mm² sehr viel besser aus.

wenn die kerne nicht gleichzeitig arbeiten ist es im prinzip siliziumverschwendung und damit rausgeschmissenes geld.

Kommt aufs Ziel an, in der Regel macht man das um möglichst effizient im Idle bzw. bei wenig Last zu sein.

Gast

2020-07-19, 19:30:13

Ich kenne keinen Test, indem es für die gängigen, weit verbreiteten ARM-Vertreter jeweils sauber überprüft wurde...

Bei den Anandtech In-depth-Architektur-Reviews gibt es oftmals derartige Tests, in der Regel aber nur auf der maximalen Performance des jeweiligen Kerns.

seba86

2020-07-20, 00:13:33

BlacKi

2020-07-20, 00:42:28

Ich verstehe nicht ganz den Sinn des big.Little-Prinzips, wenn jetzt schon alle Kerne völlig unabhängig voneinander zwischen 0.8 und 5.2 Ghz switchen können... 800 Mhz sind nur 15% der 5.2 Ghz...das Prinzip existiert doch damit schon auf den aktuellen CPUs... -.-
ein golden cove kern wird größer als 4 kleine kerne. die 4 kleinen kerne können in manchen oder generell in multicore aufgaben mehr abarbeiten als ein einzelner golden cove kern, aber man braucht die großen kerne für die schlecht skalierenden aufgaben.

desweiteren gib es zb. in spielen viele einzelne schwach ausgelastete threads. diese können dann die little cores übernehmen, während der große kern den hauptthread bearbeitet.

Gast

2020-07-20, 01:38:51

Ich verstehe nicht ganz den Sinn des big.Little-Prinzips, wenn jetzt schon alle Kerne völlig unabhängig voneinander zwischen 0.8 und 5.2 Ghz switchen können... 800 Mhz sind nur 15% der 5.2 Ghz...das Prinzip existiert doch damit schon auf den aktuellen CPUs... -.-

Irgendwann ist der Punkt erreicht an dem man mit weniger Takt kaum mehr einen geringeren Verbrauch erreicht.

Jetzt mal als reine Hausnummern, ein "großer" Kern kann bei 0,8GHz immer noch mehr Strom verbrauchen als ein "kleiner" Kern bei 2GHz, und der kleinere Kern ist dabei sogar schneller.

Umgekehrt müsstest du einen kleinen Kern hypotetisch auf 10GHz takten um die Performance eines großen Kernes bei Normaltakt zu erreichen, nur falls dieser das überhaupt schaffen würde (was eh nicht geht) bräuchte dieser dann ein vielvaches vom Strom des großen Kernes.

lumines

2020-07-20, 10:53:21

seba86

2020-07-20, 11:28:49

Deine 15% lassen es auch so klingen, als würde die Leistungsaufnahme komplett linear mit dem Takt skalieren. Auch das ist nicht der Fall.

Stimmt, der Sweetspot von Skylake lag irgendwie um 2 Ghz herum nach meinen Cinebench-Verbrauchmessungen..darüber hinaus nahm der Verbrauch überproportional zu, darunter war der Grundverbrauch zu hoch, um die 800 Mhz effizenter zu betreiben.

Andererseits sehe ich bei CoreTemp "Power used by Cores" 0.1W im Idle @800Mhz @9900KS (bei Cinebench R15 Single-Corelast meist 0.8W), während das gesamte Package 6-7W verbraucht.

Anderseits haut mich der Cinebench SCore von 251Punkten nicht wirklich von den Socken, wenn ein Ryzen 3500U (15W TDP mit Grafik ) 650 Punkte schafft...

Sind die 6W von der Lakefield nur auf die Cores oder das gesamte Package anwendbar?

Gast

2020-07-20, 14:20:49

Sind die 6W von der Lakefield nur auf die Cores oder das gesamte Package anwendbar?

Das gesamte Package.
Wobei das Samsung Notebook laut Aussage einiger Tester überhaupt auf 5W konfiguriert läuft und erst irgendwann ein Firmware-Update erscheinen soll, dass es auf 7W laufen lässt.

Tobalt

2020-07-20, 15:19:00

macht es bei big little Sinn die SMT logik aus den großen Kernen zu streichen? spart power und Fläche und ist bei den schlecht skalierenden Apps am Ende noch schneller.
Die gut skalierenden Apps, die traditionel von SMT profitieren würden von 4 little cores sicher auch gut profitieren

Insgesamt: Können bei big little die big cores etwas mehr in richtung single thread leistung optimiert werden, als bei normalen multicore CPUs ?

Gast

2020-07-20, 15:46:25

macht es bei big little Sinn die SMT logik aus den großen Kernen zu streichen? spart power und Fläche und ist bei den schlecht skalierenden Apps am Ende noch schneller.

Nein, power spart es gar keine sofern nicht aktiv und die Logik ist vernachlässigbar klein.

Die gut skalierenden Apps, die traditionel von SMT profitieren würden von 4 little cores sicher auch gut profitieren

Kerne mit schlechter Single-Thread-Performance oder genauer die schlechter ILP ausnützen können profitieren normalerweise stärker von SMT.

Insgesamt: Können bei big little die big cores etwas mehr in richtung single thread leistung optimiert werden, als bei normalen multicore CPUs ?

Im Mobilbereich ist dass das Ziel, ich glaube kaum das im Desktopbereich großartig mehr Singlethreadperformance die man aus energetischen Gründen nicht nutzt drinnen ist.

BlacKi

2020-07-20, 16:29:02

also alderlake ist mit 32threads gesehen worden. ob es sinn macht es zu streichen kann ich dir nicht sagen, aber intel scheint es drin zu lassen.

Der_Korken

2020-07-20, 16:39:51

Ich glaube, dass SMT einfach von der Implementierung zu billig ist, um auf die Vorteile zu verzichten. Es hängt natürlich auch davon ab, wie genau sich die little cores zu den big cores verhalten und wieviele es von jeder Sorte gibt.

Wenn man die little cores für parallele Rechenlast nutzt, macht SMT bei den kleinen Kernen schon Sinn. Tremont scheint von der IPC her ja immerhin irgendwo auf Sandy Bridge bis Haswell Level unterwegs zu sein und da hat SMT viel gebracht. Eventuell verzichtet man bei den big cores auf SMT, wenn diese eh nur "selten" und für einen Thread benutzt werden. Bei 1+4 (Lakefield) ergibt das Sinn, weil bei MT-Last der große Kern nicht mitrechnet, um den kleinen Kernen nicht den Strom zu klauen. Bei 8+8 (Alder Lake) sind die kleinen Kerne ja eher eine nette Dreingabe, aber die Hauptlast werden die großen Kerne tragen. Bei parallelen Anwendungen sind die 8 kleinen Kerne nicht schnell genug, sodass beide Kerntypen mitrechnen müssen. Da macht SMT plötzlich auch bei den großen Kernen wieder Sinn.