PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Welche Chancen werden big.LITTLE im Desktop-Bereich eingeräumt?


Leonidas
2021-07-18, 10:02:23
Link zur Umfrage:
https://www.3dcenter.org/umfrage/umfrage-welche-chancen-werden-biglittle-im-desktop-bereich-eingeraeumt


Link zur Umfrage-Auswertung:
folgt

Rabiata
2021-07-18, 10:43:14
Ich denke, die Anwort liegt irgendwo in der Mitte.

Ich könnte mir vorstellen, daß der Ansatz dann etwas bringt, wenn nur "leichtes Websurfen" angesagt ist, und der Stromverbrauch dann angenehm niedrig ausfällt. Bei dem Marktanteil von Intel werden sich auch die Betriebssystem-Hersteller zeitnah an eine Unterstützung machen, falls nicht schon geschehen.

Andererseits wäre auch denkbar, daß AMD so etwas wie einen Ryzen aus der U-Serie für den Desktop bringt. Die Boost- Frequenzen für den Takt sind nicht viel kleiner als beim Desktop, das könnte dann vielleicht sogar als Dauerlast am Desktop gehen. Beim "leichten Websurfen" wäre dann der Verbrauch auch sehr gering.

Platos
2021-07-18, 10:49:18
In der Umfrage wird leider nicht erwähnt, um was für Verbesserungen es sich handelt? Leistung? Effizienz? Oder was?

Das Big Little Konzept verbessert vor allem die Effizienz und da erwarte ich erhebliche Vorteile. Von daher habe ich auch so abgestummen.

Rooter
2021-07-18, 10:59:51
Stromverbrauch im Idle wird halt sinken, hoffe ich mal. Das nutzt am Desktop aber nur der Umwelt und meinem Geldbeutel.
Am Laptop kann man damit aber vielleicht der Laufzeit von Apples M1 zumindest näher kommen.

MfG
Rooter

bad_sign
2021-07-18, 11:14:47
Bei AMD sehe ich im Desktop keine Vorteile, die Cores skalieren wahnsinnig gut nach unten. Was den unteren Strich zieht, ist der IF zwischen IO und Chiplet. Sollten also kleine Cores (2 Stk zB.) in den IO wandern, dann könnte der Idle deutlich sinken, wenn man dann alle Chiplets abschaltet.

Intel muss aufholen mit Rohpower (also Cores), also weniger ein Mittel um Idle zu senken, eher um mehr Power in den Monolithen zu stopfen, ohne das der Die explodiert.

Aroas
2021-07-18, 11:27:57
Im Desktop sehe ich da keinerlei Vorteil.
Solch ein Aufbau ist für Geräte sinnvoll, die ihre Energie aus einem Akku beziehen. Hängt der Computer an einer Steckdose, ist es schlicht unnötig, irgendwelche besonderen Stromsparkerne zu nutzen.
Aber da hat wohl jeder seine eigene Philosophie.

Ich sehe jedenfalls keinerlei Sinn darin, mit eine 16 Kern CPU zu kaufen, bei der dann nur 8 Kerne wirklich richtig Power haben.
Denn will ich 16 Kerne, dann auch sollen die auch vollwertig sein, weil ich die entsprechende Leistung will.
Was soll ich mit 8 "Stromsparkernen"? In Niedriglastszenarien, wo diese Kerne aufgrund ihrer Effizienz sinnvoll sein können, brauche ich sicher keine 8 Stück davon.
Das Bisschen Internet und Office läuft auch wunderbar auf vielleicht zwei oder gar einem Kern.

Na mal schauen, wie sich das letztlich alles so entwickelt und wie die Leistung von Alder Lake aussieht.

Gast
2021-07-18, 11:29:01
Hängt davon ab was man am Desktop macht.

Für >90% der Anwendungen sind die "normalen" 8 Kerne, bzw. eigentlich oft auch schon 6 absoluter Overkill, mehr Kerne egal ob groß oder klein bringen da gar nichts mehr.

Potential hat heterogenes Multiprocessing eher in anderen Gebieten. Einerseits kann der Idle-Verbrauch weiter verringert werden, wobei das Ganze hier unbedingt mit einem effizienten 12VO Netzteil verbaut werden muss, ansonsten frisst das Netzteil in diesen Low-Power-Bereichen viel zu viel als dass die CPU noch einen wirklichen Unterschied machen kann (zumindest wenn man von einer Intel-CPU kommt)
Interessant also vor allem für Systeme die den ganzen Tag mit wenig Volllast rennen, eventuell auch für Selbstbau-NAS oder ähnliches, was dann aber nicht mehr wirklich eine Desktop-Anwendung ist.

Nächste Möglichkeit in der das Ganze was bringen kann ist in Multiprocessing-Situationen, in denen in den wenige oder überhaupt nur 1 Thread die Hauptlast trägt und damit die Performance limitiert, während es nebenher viele kleine Threads gibt die zwar auch etwas Last erzeugen aber nicht limitierend sind. Hier könnte man die kleineren Threads auch auf die kleinen Kerne legen und damit etwas an Powerbudget freilegen, die dann der große Kern verwenden kann um den eigentlich limitierenden Thread schneller abzuarbeiten.

Das setzt natürlich ein gutes Scheduling voraus, das eine solche Situation auch erkennt und die Threads entsprechend verteilt. Das Potential dürfte hier auch höchstens im einstelligen Prozentanteil liegen, und natürlich auch nur wenn das Szenario überhaupt Powerlimitiert ist, wenn man die CPU generell ohne Limit betreibt kann man hier natürlich auch nicht profitieren.

Die Situation in der heterogene Architekturen einen großen Unterschied sind jene die quasi Perfekt mit den vorhandenen Kernen skalieren. Diese Situationen sind quasi immer Powerlimitiert und mit kleinen Kernen kann man deutlich mehr Arbeit pro Engergieeinheit leisten als mit den fetten großen.
Damit das wirklich gut funktioniert braucht es aber wesentlich mehr kleine Kerne als große. Alder Lake mit seinen 8+8 ist hier nur der Anfang. Das ist also eher eine langfristige Zukunftsaussicht, wenn wir vielleicht mal 8 + 16 oder gar noch mehr kleine Kerne haben.
Auch sind derartige Situationen am Desktop eher rar, das wichtigste für Desktop ist die maximale Singlethread Rechenleistung, und das wird sich wahrscheinlich auch nie ändern. Für den Großteil der Desktop-Anwendungen kann heterogenes Processing also nur insoweit was bringen, als dass sie es ermöglichen bzw. erleichtern auf der anderen Seite die Singlethread-Leistung weiter auszubauen. Das kann einerseits schon beim CPU-Design beginnen, indem man die großen Kerne kompromissloser auf Leistung trimmt, anstatt die Balance zwischen Effizienz und Leistung zu halten, da man dafür ja die kleinen als Backup hat, und natürlich auch dynamisch, indem mehr vom Powerbudget für den einen Thread verwendet werden kann der die gefühlte Performance wirklich limitiert.

Lehdro
2021-07-18, 11:35:31
Stromverbrauch im Idle wird halt sinken, hoffe ich mal.
Im wirklichen wahren idle? Eher nicht, da sind wir jetzt schon extrem niedrig.

Bei minimaler/leichter Hintergrundlast (Browser etc) aber sehr deutlich, zumindest hoffe ich das. Kommt drauf an, wie viel Wert Intel auf die Schwuppzidität legt, sprich wie schnell die dicken Kerne anspringen (Race to idle), oder ob man wie AMD im Mobilebereich eher den Mittelweg geht, dass der Topboost erst verzögert kommt, wenn etwas länger Leistung abgefragt wird.


Zudem: Im Desktop sehe ich die Dinger skeptisch, im mobile Bereich bejubele ich sie.

Rooter
2021-07-18, 11:58:58
Ich meine Lasten unter 10%.

MfG
Rooter

BlacKi
2021-07-18, 13:37:51
über kurz oder lang wird big little überall einziehen, weil wir 3 sachen wollen, hohe singlethreadleistung, hohe multicoreleistung und keine 200-300w cpus. 12 big cores sind einfach quatsch. 8+8 hat da diverse vorteile, in allen belangen.

Benutzername
2021-07-18, 13:45:43
Ich denke, die Anwort liegt irgendwo in der Mitte.

Ich könnte mir vorstellen, daß der Ansatz dann etwas bringt, wenn nur "leichtes Websurfen" angesagt ist, und der Stromverbrauch dann angenehm niedrig ausfällt. Bei dem Marktanteil von Intel werden sich auch die Betriebssystem-Hersteller zeitnah an eine Unterstützung machen, falls nicht schon geschehen.

Linux kann das schon sowieso seit langem wegen der schon vorhandenen big-little Smartphones. Zugegeben das funktioniert etwas anders als das was intel macht. Aber intel wird da auch Beiträge in den Kernel einreichen.

Windows hmm so vermutlich mit Windows 15 wird es benutzbar. Ich erinnere mich da an die mehr als holperige 64-bit Umstellung.


Andererseits wäre auch denkbar, daß AMD so etwas wie einen Ryzen aus der U-Serie für den Desktop bringt. Die Boost- Frequenzen für den Takt sind nicht viel kleiner als beim Desktop, das könnte dann vielleicht sogar als Dauerlast am Desktop gehen. Beim "leichten Websurfen" wäre dann der Verbrauch auch sehr gering.


Der Verbruch ist so ja schon recht gering bei Ryzen bei niedriger Belastung. Wie andere ja schon schrieben würden ein paar kleine Kerne vermutlich was bringen damit man die Chiplets komplett abschalten kann, wenn man nur was tippt oder so. Gast ein paar Beiträge weiter oben führt das ganz gut aus.

Gast
2021-07-18, 14:14:20
Was ich eher so denke hat man die Wahl zwischen einer CPU mit 16 schnellen Kernen oder einer mit 8 schnellen und 16 langsamen. Zwei Cores im IF ist sicherlich eine gute Idee um Idle ein paar Watt zu sparen, aber wenn irgendwas mit Kernen skaliert, hat man normalerweise mehr Leistung, wenn man viele sparsamere Kerne hat als wenige schnelle.

Knuddelbearli
2021-07-18, 14:41:27
Stromverbrauch im Idle wird halt sinken, hoffe ich mal. Das nutzt am Desktop aber nur der Umwelt und meinem Geldbeutel.
Am Laptop kann man damit aber vielleicht der Laufzeit von Apples M1 zumindest näher kommen.

MfG
Rooter

eine CPU im idle braucht schon heute nur noch 1-2 Watt, aber der ganze Rest drum herum, haut dann nochmal 10-50 Watt da drauf, also da kann es keine wirklichen Fortschritte geben.

iamthebear
2021-07-18, 15:26:56
Aus Sicht der Energieeffizienz bei leichter Hintergrundlast bringt es nichts, da es beim Desktop (und auch bei Notebooks) keinen connected Standby gibt bzw. gar keine Anwendungen, die diesen sinnvoll nutzen würden.

Wo es jedoch viel bringen kann ist bezüglich der Effizienz pro Fläche. Allerdings wird man von den Vorteilen bei Alder Lake noch nicht viel merken. Das wird erst bei Raptor Lake spürbar werden.

Daredevil
2021-07-18, 15:30:25
Aus Sicht der Energieeffizienz bei leichter Hintergrundlast bringt es nichts, da es beim Desktop (und auch bei Notebooks) keinen connected Standby gibt bzw. gar keine Anwendungen, die diesen sinnvoll nutzen würden.

Warum gibt es wohl kein Connectet Standby? Weil der Verbrauch hoch ist. Du würdest dein Rechner doch nie mehr ausschalten, wenn er nur 5w zieht.
Der M1 iMac macht’s ja vor, wie sowas läuft.
Immer up2date, immer online, immer sofort startbereit.

Deswegen hoffe ich stark, das dieses Konzept quasi überall Verwendung findet. Durch kleine Prozessoren als Zusatz werden größere entlastet und der Verbrauch allgemein sinkt stark ab.
Eine CPU muss für nen Windows Update nicht aufdrehen, wenn es eine kleine macht, die wenige Watt verbraucht. Dazu braucht es aber Software, die das intelligent steuert.

Rooter
2021-07-18, 15:41:07
eine CPU im idle braucht schon heute nur noch 1-2 Watt, aber der ganze Rest drum herum, haut dann nochmal 10-50 Watt da drauf, also da kann es keine wirklichen Fortschritte geben.Tja, dann weiß ich nicht was das Ziel des Ganzen sein soll. :confused:

MfG
Rooter

Der_Donnervogel
2021-07-18, 15:43:24
Linux kann das schon sowieso seit langem wegen der schon vorhandenen big-little Smartphones. Zugegeben das funktioniert etwas anders als das was intel macht. Aber intel wird da auch Beiträge in den Kernel einreichen.

Windows hmm so vermutlich mit Windows 15 wird es benutzbar. Ich erinnere mich da an die mehr als holperige 64-bit Umstellung.Ich denke die beiden Dinge lassen sich nicht vergleichen. Ich sehe keine Grund warum big.LITTLE nicht gleich schon vom Start her voll unterstützt werden sollte.

Die 64-Bit-Umstellung war um vieles schwieriger und aufwändiger als es die Unterstützung von big.LITTLE ist, da viel mehr Teile des Betriebssystems betroffen waren. Außerdem wurde die Basisarbeit für big.LITTLE schon längst gemacht. Es ist schon lange so, dass der Taskscheduler nicht jeden Kern gleich behandeln kann. Spätestens seit es Prozessoren mit mehr als einem Kern und HT gab, waren nicht mehr alle logischen Kerne gleichwertig. Seither sind dann z.B. noch durch die ganzen feingranularen Stromspar- und Boostmodi der CPUs noch viele weitere Anforderungen an den Scheduler dazu gekommen. Da fügt sich big.LITTLE nahtlos ein.

Aroas
2021-07-18, 17:32:27
Hängt davon ab was man am Desktop macht.

Für >90% der Anwendungen sind die "normalen" 8 Kerne, bzw. eigentlich oft auch schon 6 absoluter Overkill, mehr Kerne egal ob groß oder klein bringen da gar nichts mehr.


Wenn ich nicht den passenden Usecase für 16 Kerne habe, dann kaufe ich mir keinen 16 Kerner, so einfach ist das.
Dann nehm ich halt nur nen 4 Kerner, wenn ich nur ne Office/Multimedia Kiste betreiben will.

In Sachen Stromsparen sehe ich es allerdings als deutlich sinnvoller an, CPUs mit "großen" Kernen mit entsprechend gut arbeitenden Stromsparmechanismen auszustatten, die dann halt bei geringer Last mehrere Kerne schlafen legen, statt die CPUs von vornherein zu "verkrüppeln" indem man 8 vollwertigen Kernen 8 "Effizienzkerne" (oder wie auch immer man das nennen will) zur Seite stellt.

Mega-Zord
2021-07-18, 17:44:56
Hängt auch erheblich von der OS-Unterstützung ab. Win11 ünterstützt es ja auf dem Papier. Da geht hoffentlich auch was.

Gast
2021-07-18, 17:46:23
eine CPU im idle braucht schon heute nur noch 1-2 Watt, aber der ganze Rest drum herum, haut dann nochmal 10-50 Watt da drauf, also da kann es keine wirklichen Fortschritte geben.


Bei Intel, bei AMD sind es eher 20-30W

Gast
2021-07-18, 17:50:01
Kommt drauf an, wie viel Wert Intel auf die Schwuppzidität legt, sprich wie schnell die dicken Kerne anspringen (Race to idle), oder ob man wie AMD im Mobilebereich eher den Mittelweg geht, dass der Topboost erst verzögert kommt, wenn etwas länger Leistung abgefragt wird.


Das ist nicht wirklich die Wahl von Intel sondern vom jeweiligen Betriebssystem, und dieses wird wahrscheinlich aufgrund diverser Parameter entscheiden wie viel Wert man auf Energieeffizienz und wieviel auf Schwuppdizität legt.

Darkman.X
2021-07-18, 18:07:16
In Sachen Stromsparen sehe ich es allerdings als deutlich sinnvoller an, CPUs mit "großen" Kernen mit entsprechend gut arbeitenden Stromsparmechanismen auszustatten, die dann halt bei geringer Last mehrere Kerne schlafen legen, statt die CPUs von vornherein zu "verkrüppeln" indem man 8 vollwertigen Kernen 8 "Effizienzkerne" (oder wie auch immer man das nennen will) zur Seite stellt.

Es gibt ja solche Stromsparmechanismen, auch von Windows -> z.B. das Core-Parking, welches aber seit Win10 (oder schon Win8) deaktiviert wurde, weil es die Performance z.B. bei WinRAR reduzierte. Und vermutlich wegen der daraus resultierenden negativen Mundpropaganda.

Die Mechanismen müssen auch von den Anwendern angenommen werden...

Daredevil
2021-07-18, 18:08:31
Idle ist ja irrelevant, sonst kann man den Rechner auch ausschalten.
Es geht um leichte Last, die z.B. durch Mails, Updates, Synchs zustande kommen, dort werden beim Ryzen z.B. die schnellen Kerne aufgeweckt und die Kiste verbrät für solche nicht zeitkritischen Dinge nun 30-40w als Hexacore. Die können aber auch einfach schlafen bleiben, wenn es Kerne gibt, die 1/4 so schnell sind und 1/10 soviel saufen. ( Das sind die Unterschiede, wenn mich meine Erinnerung nicht trügt bei den M1 Kernen )

iamthebear
2021-07-18, 18:33:27
Warum gibt es wohl kein Connectet Standby? Weil der Verbrauch hoch ist. Du würdest dein Rechner doch nie mehr ausschalten, wenn er nur 5w zieht.
Der M1 iMac macht’s ja vor, wie sowas läuft.
Immer up2date, immer online, immer sofort startbereit.

Sofort Startbereit und so gut wie kein Energieverbrauch hast du auch mit dem normalen Standby. Der Unterschied ist lediglich, dass hierbei keine Hintergrundaufgaben erledigt werden.
Das mit den Hintergrundaufgaben ist bei Smartphones deshalb wichtig, da der Nutzer dieses während der Nichtnutzung in der Regel immer eingesteckt oder in der Nähe hat und dieses akustische Benachrichtigungen gibt z.B. wenn man angerufen wird, wenn eine WA Nachricht oder SMS kommt, wenn in der Früh der Wecker läutet oder man sich einen Timer gestellt hat, wenn ein Email kommt etc.
Bei einem PC oder Notebook ist der Nutzer in der regel während der Nichtnutzung nicht vor dem Gerät. Es macht also wenig Sinn wenn hier ständig auf Chatnachrichten/Mails etc.

Das einzige, was mir spontan einfällt, wo das sinnvoll säre ist ein PC, der Dienste bereitstellt z.B. Dateien freigeben, Remotezugriff etc. Das ist jedoch ein ziemlicher Nischenmarkt. Wenn man das als Privatperson haben will, dann hat man in der Regel ein NAS. Als Firma hat man sowieso einen Server, der rund um die Uhr läuft und da hat man in der Regel ganz andere Stromfresser im Serverraum als die 2-3 Watt, die aktuelle CPUs noch im Idle verbraten.

Deswegen hoffe ich stark, das dieses Konzept quasi überall Verwendung findet. Durch kleine Prozessoren als Zusatz werden größere entlastet und der Verbrauch allgemein sinkt stark ab.

Dafür braucht man nicht zwingend Little Cores mit eigenem Silizium. Da reicht es, wenn einfach das Boostverhalten geändert wird. Selbst aktuelle CPUs können so getaktet werden, dass sie verdammt wenig Verbrauch haben.
Ich habe das vor ein paar Wochen mit einem Leonovo Thinkbook mit 35W Tiger Lake ausprobiert.
Am Netzbetrieb und Volllast zieht das Ding im Boost bis zu 50W, dauerhaft 35W und mit 1 Core Turbo waren glaube ich auch um die 20W.
Sobald man in den Batteriebetrieb wechselt hat die CPU eine maximale TDP von 8W, auf allen 4 Kernen mit 8 Thread in Cinebench. Das sind 2W pro Kern. Klar ein Little Core könnte das vielleicht mit 1W erreichen aber die Frage ist, ob bei einem Desktop PC bzw. größerem Notebook eine Differenz von 1W und das auch nur während der Hintergrundlast wirklich relevant sind. Da sollte man eher einmal bei so Dingen wie Switches/Routern anfangen, die alle überhaupt kein Energiemanagement haben und auch im Idle vor sich hin glühen.

Eine CPU muss für nen Windows Update nicht aufdrehen, wenn es eine kleine macht, die wenige Watt verbraucht. Dazu braucht es aber Software, die das intelligent steuert.

Was ist, wenn das Windows Update manuell angestoßen wurde und man gerade darauf wartet, dass es erledigt wird. Da will ich beim Netzbetrieb nicht, dass das auf einen Little Core gelegt wird, wenn die Big Cores auch alle verfügbar sind. Da müsste man viel mehr Arbeit in das Prioritätensystem investieren aber nicht auf OS Seite, sondern auf Anwendungsseite.

Ich denke die beiden Dinge lassen sich nicht vergleichen. Ich sehe keine Grund warum big.LITTLE nicht gleich schon vom Start her voll unterstützt werden sollte.

Die 64-Bit-Umstellung war um vieles schwieriger und aufwändiger als es die Unterstützung von big.LITTLE ist, da viel mehr Teile des Betriebssystems betroffen waren. Außerdem wurde die Basisarbeit für big.LITTLE schon längst gemacht. Es ist schon lange so, dass der Taskscheduler nicht jeden Kern gleich behandeln kann. Spätestens seit es Prozessoren mit mehr als einem Kern und HT gab, waren nicht mehr alle logischen Kerne gleichwertig. Seither sind dann z.B. noch durch die ganzen feingranularen Stromspar- und Boostmodi der CPUs noch viele weitere Anforderungen an den Scheduler dazu gekommen. Da fügt sich big.LITTLE nahtlos ein.

Die 64Bit Umstellung war deshalb unter Windows so mühsam, weil unter Windows in der Regel kompilierter Code verteilt wird und zwar nicht nur in Form von .exe Dateien, sondern auch in Form von .dlls. Eine 64 Bit exe kann keine 32 Bit dll laden. Wenn man nun jedoch dlls verwendet, für die es keine 64 Bit Version gibt, dann darf man seine Anwendung nich als 64 Bit Anwendung kompilieren. Da ein Großteil der Anwendung nicht einmal ansatzweise in die Nähe von 2GB RAM bedarf für einen einzelnen Prozess kommt (Spiele einmal ausgenommen), so erklärt das, warum sich kein Softwarehersteller die Arbeit antut. Die paar % mehr Performance, die man durch die zusätzlichen Register bekommt kann man in der Regel ziemlich vernachlässigen.

Im Fall von Big Little kommt es darauf an, was man damit erreichen will:
.) Geht es darum die Little Cores wie auf Smartphones (z.B. bei 10" Windows Tablets) im Hintergrund arbeiten zu lassen, so ist das relativ aufwendig, da die Anwendung dies zuerst einmal dem Betriebssystem richtig mitteilen muss, ob es eine Hintergrundaufgabe durchführt oder nicht. In der Regel wird das zumindest derzeit nicht gemacht.

.) Geht es darum die Little Cores bei Multi Core optimierter Software dazu zu schalten, so sollte das Ganze relativ einfach sein. Zuerst werden die Big Cores verwendet, dann der 2. Thread der Big Cores (bei SMT) und dann die Little Cores, wobei falls die Little Cores sehr performant sind es eventuell auch Sinn machen könnte zuerst die Little Cores zu belasten und dann erst den 2. Thread der Big Cores bzw. es könnte auch ziemlich egal sein.
Was die Sache jedoch verkomplizieren könnte ist, dass die Little Cores nicht dieselben Features unterstützen z.B. kein AVX. Was passiert mit einem laufenden Prozess, wenn dieser während der Ausführung von AVX Code auf einen non AVX Little Core verschoben wird?

.) Die große Aufgabe für den Scheduler liegt jedoch nicht in Alder Lake, sondern das, was danach kommt. Das Ziel der Little Cores ist ja, dass man damit die Anzahl der Cores generell erhöhen kann und wenn man es einmal mit 50-100 Kernen oder mehr Desktop zu tun hat, dann ist die Frage wie gut der Scheduler noch damit umgehen kann. Sobald das Ganze dann im Servermarkt ankommt, werden es noch einmal deutlich mehr Kerne werden. Die Frage ist nicht, ob der Windows Scheduler mit den 16 Kernen eines Alder Lake 12900K zu Recht kommt, sondern ob er mit einer Dual Sockel Server CPU mit je 256 Kernen zu Recht kommt.

Wenn ich nicht den passenden Usecase für 16 Kerne habe, dann kaufe ich mir keinen 16 Kerner, so einfach ist das.
Dann nehm ich halt nur nen 4 Kerner, wenn ich nur ne Office/Multimedia Kiste betreiben will.

Was ist, wenn ich aber nicht Geld sparen will, sondern meine Single Core Software möglichst schnell betreiben will? Da hole ich mir lieber 8 Big Cores + 8 Little Cores statt 4 Medium Cores ;-)

In Sachen Stromsparen sehe ich es allerdings als deutlich sinnvoller an, CPUs mit "großen" Kernen mit entsprechend gut arbeitenden Stromsparmechanismen auszustatten, die dann halt bei geringer Last mehrere Kerne schlafen legen, statt die CPUs von vornherein zu "verkrüppeln" indem man 8 vollwertigen Kernen 8 "Effizienzkerne" (oder wie auch immer man das nennen will) zur Seite stellt.

Sehe ich auch so, wobei auf CPU Seite die Stromsparmaßnahmen im Mobile Bereich eigentlich schon sehr gut sind.

Daredevil
2021-07-18, 18:58:18
Was ist, wenn das Windows Update manuell angestoßen wurde und man gerade darauf wartet, dass es erledigt wird. Da will ich beim Netzbetrieb nicht, dass das auf einen Little Core gelegt wird, wenn die Big Cores auch alle verfügbar sind. Da müsste man viel mehr Arbeit in das Prioritätensystem investieren aber nicht auf OS Seite, sondern auf Anwendungsseite.

Du musst ja nichts manuell anstoßen, wenn es effizient und unsichtbar im Hintergrund bereits vorgeladen wurde und ggf. Nachts einfach selbst installiert wird.
Ein Smartphone ist Kinderleicht zu bedienen, verbraucht super wenig Energie und ist dabei noch ( für den Verbrauch... ) extrem schnell.
Diese drei Komponenten würde ich mir für den Desktop auch einfach wünschen.

Man muss sicherlich nicht immer den gleichen Hersteller nennen, aber Apple und der iMac ist nun mal das beste Beispiel.
Sparsam, schnell, immer Online.
Mir ist auch bewusst, das andere Hersteller bereits die "80%" genommen haben bis zu diesem Status, die Herausforderung sind aber nun einmal die letzten 20%.

Freestaler
2021-07-18, 19:07:48
Wo kann man negative ankreuzen? Ich sehe vorallem Nachteile. Silizium wird falsche verbraucht und man muss es trotzdem Bezahlen. Von den skizzierten Vorteilen sind wir im Desktop mMn. lichtjahre entfernt. Solange alle umgebenden Komponetten 10x bis 50x Fache verbrauchen. Auch die readystandby Geschichten sind doch schnee von gestern. Für die 0,3 Sekunde mailabgleich oder das eine Update im Monat dauernd 1-5 Watt zuverbrauchen ist nonsense.

Ps apple m1 mini nimmt sich 7watt. Die Umwelt dankt.

Gast
2021-07-18, 19:09:28
In Sachen Stromsparen sehe ich es allerdings als deutlich sinnvoller an, CPUs mit "großen" Kernen mit entsprechend gut arbeitenden Stromsparmechanismen auszustatten, die dann halt bei geringer Last mehrere Kerne schlafen legen, statt die CPUs von vornherein zu "verkrüppeln" indem man 8 vollwertigen Kernen 8 "Effizienzkerne" (oder wie auch immer man das nennen will) zur Seite stellt.

Da macht dir nur blöderweise die Physik einen Strich durch die Rechnung.

Damit die großen Kerne so schnell sind sollen sie ja möglichst hoch takten. Allerdings erhöhen Maßnahmen im Chipdesign, welche die Taktbarkeit verbessern auch die Leckströme, was dann die mögliche Effizienz bei geringem Takt verschlechtert.

Damit sind die Möglichkeiten für identische Hardware die gleichzeitig super schnell und super sparsam sein soll eben begrenzt. Dazu kommt dass die schnelle Stromsparmaßnahme des Clock-Gating eben die Leckströme nicht verhindert. Damit wird nur der aktive Stromverbrauch verhindert.
Powergating dagegen kann zwar auch die Leckströme ausschalten, ist aber in Hardware deutlich aufwändiger und braucht auch einige 10 bis einige 100 Takte um einzelne Blöcke ein und auszuschalten, ist also prinzipiell nicht so feinkörnig möglich, und auch nur für Blöcke bei denen bekannt ist dass man sie einige Zeit nicht brauchen wird.

Dazu kommt noch dass das Dennard Scaling schon längere Zeit tot ist und damit bei der Prozessentwicklung der Stromverbrauch pro Gate wesentlich langsamer abnimmt als die Dichte der Gates. Mit jedem Prozesschritt der dir eine Verdopplung der Gatedichte bringt braucht jedes Gate immer noch 70-80% des Stroms.
Damit kannst du bei modernen Prozessen gar nicht mehr alle Gates die du verbauen kannst gleichzeitig nutzen, weil damit der Verbrauch viel zu stark ansteigen würde.

Damit wird es sinnvoll, die mögliche höhere Integrationsdichte für immer mehr spezialisierte Hardware zu nutzen welche für das jeweilige Einsatzgebiet optimiert sind, anstatt immer mehr Alleskönner aneinander zu reihen, welche man eh gar nicht mehr alle gleichzeitig nutzen kann.
Die CPUs sind da eh recht spät dran, da diese prinzipbedingt schon seit jeher hohe Anteile an dead silicon haben, aber auch diese werden von der Physik eingeholt, es ist jedenfalls nicht absehbar, dass das Power-Scaling jemals wieder mit dem Densitiy-Scaling mithalten wird können.

Daredevil
2021-07-18, 19:40:07
In Sachen Stromsparen sehe ich es allerdings als deutlich sinnvoller an, CPUs mit "großen" Kernen mit entsprechend gut arbeitenden Stromsparmechanismen auszustatten, die dann halt bei geringer Last mehrere Kerne schlafen legen, statt die CPUs von vornherein zu "verkrüppeln" indem man 8 vollwertigen Kernen 8 "Effizienzkerne" (oder wie auch immer man das nennen will) zur Seite stellt.
Warum denn nicht beides?
Diese " gut arbeitenden Stromsparmechanismen" sind doch auch bei kleinen CPUs effektiv, wieso den nur die großen damit ausstatten?
Das ist ja kein entweder oder, wenn Millionen Rechner im Idle aber nun 5-10w weniger verbrauchen, hat das einen riesigen Einfluss auf die Welt.

"Verkrüppeln" ist in dem Sinne auch zu drastisch ausgedrückt.
Ein M1 nimmt es mit einem Ryzen 5600x auf, der M1 hat ja nur "4 Kerne", da die restlichen ja verkrüppelt sind? :c
Nope. Auch viele Kerne mit wenig Takt machen lärm, sonst würde es keinen Threadripper geben mit 128 Kernen.
Denn jeder dieser Kerne ist am Ende auch nur "Low Power", wenn alle gleichzeitig genutzt werden.

Rabiata
2021-07-18, 19:47:51
Eine 64 Bit exe kann keine 32 Bit dll laden. Wenn man nun jedoch dlls verwendet, für die es keine 64 Bit Version gibt, dann darf man seine Anwendung nich als 64 Bit Anwendung kompilieren. Da ein Großteil der Anwendung nicht einmal ansatzweise in die Nähe von 2GB RAM bedarf für einen einzelnen Prozess kommt (Spiele einmal ausgenommen), so erklärt das, warum sich kein Softwarehersteller die Arbeit antut. Die paar % mehr Performance, die man durch die zusätzlichen Register bekommt kann man in der Regel ziemlich vernachlässigen.sein.
Es kommt hinzu, daß die 64 Bit Pointer auch mehr Speicherbandbreite brauchen und damit die Performance wieder runterziehen.

Die C't hat das seinerzeit mal abgeklopft und ist zum Ergebnis gekommen, daß sich 32 bit und 64 bit bei der Performance im Schnitt nichts schenken. Der Vorteil von 64 bit ist nur, daß die Anwendungen nicht auf 2GB oder 4GB RAM begrenzt sind.

Gast
2021-07-18, 20:30:17
Finally it will be a change of paradigm in the x86 (x86-64) world also in the high-end. The combination of big.LITTLE Alder Lake cores on the third generation 10nm SuperFin (as 8C/16T P-Cores Golden Cove + 8C/8T E-Cores GRACEMONT) with DDR5 memory support and PCIe 5.0 support will be an interestingly innovative blend of alchemy.

Even the next generation of Raptor Lake will have more small cores (up to 16) than big ones.

That's why I decided to follow in the footsteps of Alder Lake with the rise of small cores (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12739508#post12739508).

MD_Enigma
2021-07-18, 22:16:15
Finally it will be a change of paradigm in the x86 (x86-64) world also in the high-end.
That's why I decided to follow in the footsteps of Alder Lake with the rise of small cores (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12739508#post12739508).
Na klasse. Die mehr als 50% Single-Thread-Leistung, damit man beim Multi-Core besser dasteht. Schöne neue Welt. Die funktioniert leider genau gleich wie bei normalen Cores wenn man den Takt senkt.

Rooter
2021-07-18, 22:55:17
.) Geht es darum die Little Cores wie auf Smartphones (z.B. bei 10" Windows Tablets) im Hintergrund arbeiten zu lassen, so ist das relativ aufwendig, da die Anwendung dies zuerst einmal dem Betriebssystem richtig mitteilen muss, ob es eine Hintergrundaufgabe durchführt oder nicht. In der Regel wird das zumindest derzeit nicht gemacht.Das ist imho der Knackpunkt an der ganzen Sache! Wenn es um Hintergrundaufgaben geht, muss die Anwendung dem OS auch mitteilen, dass das hier jetzt nur Hintergrund ist. Unter Windows gibt es dafür (noch?) keine API. Ich vermute bei den mobile OS schon, oder?

Was passiert mit einem laufenden Prozess, wenn dieser während der Ausführung von AVX Code auf einen non AVX Little Core verschoben wird?Unter Windows ist das bisher nicht vorgesehen, da müssen alle Cores dasselbe können.

Auch viele Kerne mit wenig Takt machen lärm, sonst würde es keinen Threadripper geben mit 128 Kernen.
Denn jeder dieser Kerne ist am Ende auch nur "Low Power", wenn alle gleichzeitig genutzt werden.Das geht aber nur auf, wenn wir für einen Big Core gleich 3-4x so viele Little Cores kriegen (von der Die-Size käme das ja hin). Sieht aber zurzeit nicht danach aus.
Ganz abgesehen davon, dass du die vielen Cores ja auch auslasten müsstest. Nicht alles läßt sich ohne Ende parallelisieren.

MfG
Rooter

Gast
2021-07-19, 07:54:51
Das Konzept macht eigentlich nirgendwo wirklich Sinn. Wenn alle Kerne einer CPU getrennt von einander takten koennen und auch einzeln komplett abschaltbar sind, wenn bei geringen Lasten durch Hintergrunddienste nicht hoch getaktet wird, wenn evt sogar getrennt Teilbereiche eines Cores ausgeschaltet werden koennen, spaetestens dann macht das alles ueberhaupt keinen Sinn mehr. Das einzige wo das ganze wirklich schon immer etwas gebracht hatte war im Marketing. Mit nur wenig mehr Silizium konnte man so tun als haette man viel mehr zu bieten. Im Desktop ist das ganze schon heute totaler Mumpitz. Das ganze drum herum verbraucht ein vielfaches von der CPU selbst. Monitor, Grafikkarte, Lautsprechersystem, uvm. Ausserdem will ich auch beim Surfen das die Webseiten fluessig daher kommen. Zusaetzliche 100ms bei jedem Klick stoeren mich definitiv mehr als ein einstelliger durchschnittlicher Mehrverbraucht meiner Workstation.

Gast
2021-07-19, 08:12:21
Das ist imho der Knackpunkt an der ganzen Sache! Wenn es um Hintergrundaufgaben geht, muss die Anwendung dem OS auch mitteilen, dass das hier jetzt nur Hintergrund ist. Unter Windows gibt es dafür (noch?) keine API. Ich vermute bei den mobile OS schon, oder?

Jede Anwendung spawnt einen Main-Thread, der auch für die Fensterdarstellung zuständig ist. Für die gefühlte Performance ist es wichtig, dass genau dieser Thread besonders schnell abgearbeitet wird.

Entwickler sind schon seit Ewigkeiten angehalten alles was potentiell länger dauert, z.B. Festplatten- oder Netzwerkzugriffe nicht in diesem Thread zu machen sondern dafür parallele Threads zu spawnen.
Ob diese etwas schneller oder langsamer abgearbeitet werden hat keinen großen Einfluss auf die gefühlte Performance, diese können also ruhig auch auf den langsameren Kernen laufen.

Das ist es übrigens genau wenn mal Windows ein Fenster grau macht mit der Meldung Anwendung XY reagiert nicht mehr. Das heißt keinesfalls dass die Anwendung abgestürzt ist oder nichts mehr sinnvolles macht, sondern die Window Event-Queue kommuniziert ständig mit den gelaunchten Prozessen, und wenn eine Anwendung im Main-Thread mir irgendwelchen Dingen beschäftigt ist die eigentlich auf Hintergrundthreads ausgelagert werden sollten und deshalb ein paar Sekunden nicht mehr mit der Windows Event Queue kommunizieren kommt eben die entsprechende Meldung.
Bei Android ist es ähnlich die Meldung, dass eine Anwendung nicht mehr reagiert und geschlossen wird kommt dort genauso wenn eine Anwendung für einige Zeit nicht mehr mit der Event Queue kommuniziert, nur ist Android dabei noch deutlich Aggressiver als Windows und zwingt damit quasi die Entwickler alles auszulagern was irgendwie möglich ist, da man ansonsten gar nicht in den Playstore kommt.

Und genau darüber kann das Betriebssystem auch von selbst wichtige Vordergrundthreads und Hintergrundthreads voneinander trennen, ganz ohne dass das die Anwendung irgendwie explizit kommuniziert. Threads die viel mit der Event-Queue kommunizieren müssen so schnell wie möglich abgearbeitet werden, Threads die wenig bis gar nicht mit der Eventqueue kommunizieren dürfen ruhig etwas länger dauern.

Gast
2021-07-19, 08:17:11
Du musst ja nichts manuell anstoßen, wenn es effizient und unsichtbar im Hintergrund bereits vorgeladen wurde und ggf. Nachts einfach selbst installiert wird.
Ein Smartphone ist Kinderleicht zu bedienen, verbraucht super wenig Energie und ist dabei noch ( für den Verbrauch... ) extrem schnell.
Diese drei Komponenten würde ich mir für den Desktop auch einfach wünschen.

Man muss sicherlich nicht immer den gleichen Hersteller nennen, aber Apple und der iMac ist nun mal das beste Beispiel.
Sparsam, schnell, immer Online.
Mir ist auch bewusst, das andere Hersteller bereits die "80%" genommen haben bis zu diesem Status, die Herausforderung sind aber nun einmal die letzten 20%.
Gerade bei meinem Dienst iPhone stoße ich iOS Updates und App Updates aber immer manuell an, weil das Ding die Updates verspätet lädt und meiner Meinung nach auch nicht immer zuverlässig.
Beim Store habe ich schon öfters erlebt, dass ich gestern aktiv Updates installiert habe und heute sind Updates von vor 3 Tagen vorhanden. Die hätte er gestern auch schon installieren können, hat er aber warum auch immer nicht. Dein Beispiel finde ich daher eher unglücklich, denn gerade Apple macht das meiner Meinung nach nicht gut. Vermutlich fällt es nur keinem auf, weil niemand nach schaut. Wenn ich das bei Windows 10 mache, dann klappt das aber genauso gut als bei Apple, das installiert halt die Updates nebenher und nach der üblichen Nutzungszeit gibt's dann mal einen Neustart.

Redirion
2021-07-19, 09:23:31
Jede Anwendung spawnt einen Main-Thread, der auch für die Fensterdarstellung zuständig ist. Für die gefühlte Performance ist es wichtig, dass genau dieser Thread besonders schnell abgearbeitet wird.

[...]

Und genau darüber kann das Betriebssystem auch von selbst wichtige Vordergrundthreads und Hintergrundthreads voneinander trennen, ganz ohne dass das die Anwendung irgendwie explizit kommuniziert. Threads die viel mit der Event-Queue kommunizieren müssen so schnell wie möglich abgearbeitet werden, Threads die wenig bis gar nicht mit der Eventqueue kommunizieren dürfen ruhig etwas länger dauern.

Es gibt aber auch viele Anwendungen, wo es genau andersherum ist. Beispiel 7-Zip. Der Mainthread mit dem Fenster ist quasi die ganze Zeit im idle bzw. reagiert nur auf Status-Updates, während die anderen Threads mit maximalem CPU-Ressourcenbedarf dabei sind, um die Komprimierung oder Dekomprimierung zu erledigen.

Ich glaube das Thema ist durchaus komplex, ich sehe aber auch gutes Potenzial.

BlacKi
2021-07-19, 09:31:03
Na klasse. Die mehr als 50% Single-Thread-Leistung, damit man beim Multi-Core besser dasteht. Schöne neue Welt. Die funktioniert leider genau gleich wie bei normalen Cores wenn man den Takt senkt.
aber die chipfläche wird damit gesenkt. d.h. die cpu wird billiger. und mit dem starken ausbau der littlecores steigt auch der multicore vorteil und die chipfächeneinsparung.

Gast
2021-07-19, 09:47:22
Braucht es dafür eine Umfrage was der Benutzer davon hält?
Wenn man sich austauschen möchte, ja, hingegen die Resultate und Entwicklung stehen bereits fest.
Schon viele Papier die sich professionell mit dem Thema auseinandergesetzt haben, sagten schon vor Jahren voraus, dass selbst im Server-, Compute-etc.-Bereich, es stark an Effizienz und Leistung zu legen wird.

Homogene Ansätze haben beinahe eine hard-wall, was Skalierbarkeit, Effizienz und Leistung betrifft, starke diminishing returns, die in den nächsten Jahren mit dem erreichen des Litographie-Limits (1 nm und co.) sichtbar werden.
Neue zukünftige Materialien/Prozesse werden zwar die hard-wall und diminishing returns nach hinten verschieben, oder neue Leistung freischalten, ändern aber an dem eigentlichen Ergebnis - dass heterogene Ansätze dennoch effizienter sind, besser skalieren etc. - nichts.

Heterogene Ansätze haben dies bereits heute (und auch momentan nicht absehbar) nicht.
Nicht nur zwei verschiedene Mikroarchitekturen bei den Prozessorkernen, sondern auch Ko-Prozessoren und andere Beschleuniger, ebnen hier den Weg.
Deshalb ist der M1 von Apple so effizient. Selbst an 5900HX gedrosselt auf 30 W kommt nicht heran.

Mein Ryzen 5900X verbraucht (obwohl alle Sparmaßnamen an sind) im Windows-Energiesparplan "Ausbalanciert" gerade 40 - 56 W, obwohl nur der Browser und Discord laufen. Alleine das Scrollen auf der Webseite lässt den Verbrauch von 35 auf 45 W ansteigen.
Der Energiesparplan "Energiesparmodus" hingegen (CPU limitiert auf 99 %, Takt limitiert auf 3,6 GHz) pendelt sich bei 30 - 35 W ein und überschreitet dies nicht.
Das sind 35 - 85 % Einsparung.

Schauen von 4k uhd Video bei 60 fps? Ausbalanciert bis 80 W-Spitzen.
Energiesparmodus überschreitet die 40 W nicht.
So ähnlich wird es sich mit heterogenen Ansätzen verhalten.

Leonidas
2021-07-19, 10:09:31
Braucht es dafür eine Umfrage was der Benutzer davon hält?

Gemessen an der Anzahl der Forenbeiträge hierzu scheint es ein wichtiges Thema zu sein.

Ich lese hierbei viele interessante Gedankengänge, darunter auch in Deinem Posting.

Gast
2021-07-19, 11:52:22
Es gibt aber auch viele Anwendungen, wo es genau andersherum ist. Beispiel 7-Zip. Der Mainthread mit dem Fenster ist quasi die ganze Zeit im idle bzw. reagiert nur auf Status-Updates, während die anderen Threads mit maximalem CPU-Ressourcenbedarf dabei sind, um die Komprimierung oder Dekomprimierung zu erledigen.


Wenn das Fenster nicht mehr oder nur verzögert reagiert merkst du das sofort.

Ob das Entpacken jetzt ein paar Sekunden schneller oder langsamer läuft ist vollkommen egal, das ist sowieso eine längere Tätigkeit auf die man wartet. Wichtig sind dass jene Dinge die man erwartet dass sie Instant fertig sind das auch sind.

Es ist natürlich auch die Frage ob man das Scheduling auf max. Performance oder Energy Aware macht, und da wird man natürlich auch je nach Situation switchen.

Wenn man eh mit unlimitierten Powerlimit arbeitet und der Energieverbrauch komplett egal ist, wird man immer die höchste Performance erreichen indem man zuerst die schnellen Kerne auslastet und nur wenn man weitere Aufgaben hat die noch auf die kleinen zu verteilen.

Gast
2021-07-19, 12:08:14
Das ist imho der Knackpunkt an der ganzen Sache! Wenn es um Hintergrundaufgaben geht, muss die Anwendung dem OS auch mitteilen, dass das hier jetzt nur Hintergrund ist. Unter Windows gibt es dafür (noch?) keine API. Ich vermute bei den mobile OS schon, oder?

Was genau soll denn die Anwendung mitteilen? Entweder hat die Anwendung etwas zu berechnen, dann bekommt sie auch Rechenzeit zugeteilt, oder eben nicht, weil sie auf etwas wartet (Benutzereingaben, Timer, Netzwerk, was auch immer). Dann braucht sie auch keine Rechenzeit und bekommt vom Scheduler auch keine.


Ganz abgesehen davon, dass du die vielen Cores ja auch auslasten müsstest. Nicht alles läßt sich ohne Ende parallelisieren.

Nicht nur nicht alles, sondern genau genommen gar nichts.


Und genau darüber kann das Betriebssystem auch von selbst wichtige Vordergrundthreads und Hintergrundthreads voneinander trennen, ganz ohne dass das die Anwendung irgendwie explizit kommuniziert. Threads die viel mit der Event-Queue kommunizieren müssen so schnell wie möglich abgearbeitet werden, Threads die wenig bis gar nicht mit der Eventqueue kommunizieren dürfen ruhig etwas länger dauern.
Soweit so gut, aber das würde bedeuten, dass die langlaufenden, rechenintensiven threads nur auf den langsamen Kernen laufen würden und damit der Prozessor künstlich in seiner Leistungsfähigkeit beschnitten würde.
Oder der Scheduler vergibt dynamische Prioritäten und nutzt alle Kerne, aber dann erschließt sich mir nicht, was die langsamen Kerne bringen sollen.

Lehdro
2021-07-19, 16:22:36
Das ist nicht wirklich die Wahl von Intel sondern vom jeweiligen Betriebssystem, und dieses wird wahrscheinlich aufgrund diverser Parameter entscheiden wie viel Wert man auf Energieeffizienz und wieviel auf Schwuppdizität legt.
Stimmt so nicht. Das legt immer noch der OEM und im erweiterten Falle damit der Hersteller fest. Ich empfehle dazu mal zu recherchieren wie viele Ryzen im Mobilebetrieb boosten, komplett konträr zum Netzbetrieb, der sich eher analog zu den Desktop CPUs verhält. Dieses Verhalten kommt primär von der Hardware, lässt sich aber unter Umständen im Windows aushebeln - im Standardbetrieb fummelt Windows da aber eben nicht rein.

Hier ein Artikel dazu (https://www.extremetech.com/extreme/317657-intel-is-spreading-fud-about-supposedly-huge-ryzen-4000-performance-drops-on-battery), das ging damals auch zurecht durch die Medien. Solch ein Verhalten beeinflusst die Schwuppzidität und die Effizienz der CPU enorm.

Gast
2021-07-19, 20:27:45
Stimmt so nicht. Das legt immer noch der OEM und im erweiterten Falle damit der Hersteller fest.

Ja und nein, grundsätzlich legt das das Betriebssystem fest. Dieses lässt sich vom OEM noch parametrisieren je nachdem was dieser bevorzugt.

Außer natürlich der OEM verwendet ein Opensource Betriebssystem und entwickelt einen eigenen Kernel, dann hat er natürlich völlig freie Hand.

Wobei selbstverständlich davon auszugehen ist, dass der jeweilige CPU-Hersteller sowohl den Betriebssystementwicklern als auch den OEMs unter die Arme greifen um das gewünschte Ziel zu erreichen.

Gast
2021-07-19, 20:29:29
Soweit so gut, aber das würde bedeuten, dass die langlaufenden, rechenintensiven threads nur auf den langsamen Kernen laufen würden und damit der Prozessor künstlich in seiner Leistungsfähigkeit beschnitten würde.

Darum geht es beim Energy Aware Scheduling auch nicht, sondern darum den gegebenen Task zu absolvieren und dabei möglichst wenig Wh zu verbrauchen.

Gast
2021-07-20, 17:57:57
Ich sehe jedenfalls keinerlei Sinn darin, mit eine 16 Kern CPU zu kaufen, bei der dann nur 8 Kerne wirklich richtig Power haben.
Denn will ich 16 Kerne, dann auch sollen die auch vollwertig sein, weil ich die entsprechende Leistung will.
Was soll ich mit 8 "Stromsparkernen"? In Niedriglastszenarien, wo diese Kerne aufgrund ihrer Effizienz sinnvoll sein können, brauche ich sicher keine 8 Stück davon.
Das Bisschen Internet und Office läuft auch wunderbar auf vielleicht zwei oder gar einem Kern.



Ich bin absolut derselben Meinung.

D.h. ich hätte dann bei Programmen, die alle Kerne verwenden, weniger Leistung als mit heutigen CPUs ( außer die IPC wird wieder drastisch gesteigert, sodaß z.B. 8 Kerne so schnell wie heute 16 sind. Aber wozu brauche ich dann überhaupt eine neue CPU?

Ich habe einen 3950x und bin äußerst zufrieden damit.

bad_sign
2021-07-20, 19:21:19
Mein Ryzen 5900X verbraucht (obwohl alle Sparmaßnamen an sind) im Windows-Energiesparplan "Ausbalanciert" gerade 40 - 56 W, obwohl nur der Browser und Discord laufen. Alleine das Scrollen auf der Webseite lässt den Verbrauch von 35 auf 45 W ansteigen.
Der Energiesparplan "Energiesparmodus" hingegen (CPU limitiert auf 99 %, Takt limitiert auf 3,6 GHz) pendelt sich bei 30 - 35 W ein und überschreitet dies nicht.
Das sind 35 - 85 % Einsparung.

Schauen von 4k uhd Video bei 60 fps? Ausbalanciert bis 80 W-Spitzen.
Energiesparmodus überschreitet die 40 W nicht.
So ähnlich wird es sich mit heterogenen Ansätzen verhalten.

Du zeigst doch genau, das man big-little eben nicht braucht, es hängt maßgeblich an der Software, bzw der Einstellung, die Hardware kann es. Zen Cores sind sofort aus, sobald keine Aufgabe da ist und ist im Bios CPPC an, wird auch intelligent Aufgaben auf die Cores verteilt ( um zB. den 2. CCD nicht aktivieren zu müssen)

Die CPUs sind auf Power gedrillt, weil man sie damit verkauft. Nimmst du ein Laptop und nutzt es im Batteriebetrieb, dann sieht die Lage ganz anders aus. Plötzlich hat man Effizienzwunder, die im normalen Desktop Betrieb nicht langsamer sind, aber bei 5W Arbeiten.


Zum Idleverbrauch generell hat hier das Bios/Mainboard Hersteller eh am meisten zu sagen. Wobei auch AMD mal reinpfuscht, wie deaktivierte (nicht aktivierbar) IF-Energiesparmaßnahmen, wenn man den IF über 1600MHz bringt (Mein Deskrop 53W vs 64W Idle von IF 1600 zu 1633)

Daredevil
2021-07-20, 19:53:05
Ich habe einen 3950x und bin äußerst zufrieden damit.
Oh ich glaube du würdest fürs Gaming einiges dafür tun, wenn aus deinem 3950x ein Prozessor wird mit 8 Zen3 und 8 Zen1 Kernen wird. :D
Das wäre quasi dann "big.LITTLE", die schnellsten High Performance Kerne auf dem Markt und ( Falls Zen1 jetzt sparsam wäre... ) effiziente Kerne für dauerhafte MT Last.
Der Speed der High Perf Kerne frisst den Nachteil der Low Perf Kerne quasi auf im MT. Währenddessen hast du Weltklasse Single Core Speed und eine Weltklasse Energie Effizienz bei leichten Tasks.

Wenn du aus einem 16c Prozessor ein big.LITTLE machst, werden 8 Kerne kleiner, während die anderen größer werden.
So könnte man das zumindest angehen. ( Apple ist damit gerade recht erfolgreich )

PS: Genauso zeichnen sich und erste Leaks ab.
https://videocardz.com/newz/intel-core-i9-12900ks-qs-allegedly-outperforms-ryzen-9-5950x-in-cinebench-r20-test
Massiv bessere SC Leistung, moderat bessere MT Leistung, erträglicher Stromverbrauch im MT.

Mal schauen ob das echt so kommt.
Das wären dann im Vergleich zu einem 3950x 54% mehr SC Leistung und 26% mehr MC Leistung.
Und das ist z.B. ne Menge für "nur 8 Große Kerne".

Gast
2021-07-20, 22:13:59
Zen Cores sind sofort aus, sobald keine Aufgabe da ist und ist im Bios CPPC an, wird auch intelligent Aufgaben auf die Cores verteilt ( um zB. den 2. CCD nicht aktivieren zu müssen)


Mit ausgeschalteten Cores kann man aber nichts machen, und es braucht immer noch einige 100e Takte um einen Core ein- bzw. auszuschalten, und ein bisschen was braucht man eigentlich immer.

Zen Cores sind nur sparsam wenn sie absolut nichts tun, wenn sie nur ganz ein bischen was zu tun haben brauchen sie sogar mehr Strom als Intel bei vergleichbar niedrigen Lasten.

Und genau da bringt big.LITTLE was, weil man kann eben in solchen Szenarien die großen Kerne absolut nichts tun lassen, und sowohl bei Intel als auch bei AMD brauchen die Cores bei geringen Lasten immer noch einige Watt, während auf Energieeffizienz getrimmte Kerne das selbe mit eine paar hundert mW machen könnten.

Bei Ryzen bringt das natürlich alles nix, weil alleine der IO-Die ~20W braucht, und das immer selbst wenn alle Kerne schlafen.

Rooter
2021-07-20, 23:40:09
Ob das Entpacken jetzt ein paar Sekunden schneller oder langsamer läuft ist vollkommen egal, das ist sowieso eine längere Tätigkeit auf die man wartet. Wichtig sind dass jene Dinge die man erwartet dass sie Instant fertig sind das auch sind.Nö, wäre mir nicht egal. ;)

Was genau soll denn die Anwendung mitteilen? Entweder hat die Anwendung etwas zu berechnen, dann bekommt sie auch Rechenzeit zugeteilt, oder eben nicht, weil sie auf etwas wartet (Benutzereingaben, Timer, Netzwerk, was auch immer). Dann braucht sie auch keine Rechenzeit und bekommt vom Scheduler auch keine.Kennst du nur Extreme? Es gibt außer 0% und 100% auch noch Lasten im niedrigen Bereich. Alle 5 Minuten die Mails vom Server abholen braucht keinen Big Core, ebenso wenig z.B. die Wiedergabe einer Audiodatei. Oder 1000 andere Sachen. Der Scheduler müsste aber ziemlich clever sein um das von selbst korrekt zu erkennen.

Wenn du aus einem 16c Prozessor ein big.LITTLE machst, werden 8 Kerne kleiner, während die anderen größer werden. Wir sollten erst mal den Begriff definieren. Was sind Big und was Little Cores, ausgehend von den heute aktuellen Kernen? Sind die Little eher so Intel Atom Niveau und die Big das was wir heute kennen oder sind die Little das was wir heute kennen (evt. mit weniger Takt) und die Big extrem aufgebohrte, riesige Monster?

MfG
Rooter

bad_sign
2021-07-20, 23:42:59
Die IO braucht etwa 12W und Zen3 Cores sind deutlich effizienter als Intel Cores bei gleicher Leistung, siehe Notebooks oder 5600X. Was Zen3 am PC die Effizienz zunichte macht, ist AMDs "tolle" 1,5V Boost Spannung.

Daredevil
2021-07-21, 00:47:24
I dont know. :)
Aber ja, das ist halt wichtig zu wissen.
Der M1 hat vier extrem große und schnelle Kerne und vier, die nur 1/10 des Stroms ziehen. ( Wenn man bei der TDP von groß sprechen kann, der Transistor Count ist aber riesig )
Erste Leaks zu Intels Kiste zeigen vermutlich Ähnliches, sonst wäre der SC Score nicht so unglaublich hoch. ( oder es ist halt ne Ente )

Gast
2021-07-22, 12:48:51
Die IO braucht etwa 12W

Aber auch nur mit JEDEC Speicher.

Bei moderatem DDR3600 sind es schon eher an die 20W.

FlashBFE
2021-07-23, 15:14:49
[X] sehe für den Desktop-Bereich generell keinen beachtbaren Vorteil

Für's primäre Stromsparen sind es im Desktop unnötige Transistoren, denn die modernen x86-CPUs sind im Leerlauf schon ziemlich effizient. Außerdem hat im Desktop der Rest des Systems eine relativ hohe Grundlast, weswegen weiteres Sparen bei den CPU-Kernen nicht mehr viel bringen dürfte.

Und was Massiv-Multithreading angeht, gibt es zwei Probleme: Die meisten Programme sind aktuell mit 8 Kernen bestens versorgt, obwohl es schon lange mehr im Desktopbereich gibt und was Spiele angeht, wird es dank der Konsolen noch lange so bleiben. Bei gut parallelisierter Software wie Videocoding sehe ich dann eher noch mehr Last auf die GPUs wandern. Bei APUs wäre das dann quasi der Parallel-Coprozessor auf dem Die. Das ist aber zugegeben seit einer Weile ins Stocken geraten. Ansonsten gäbe es noch die Variante, wie ehemals IBM mit 4-fach-SMT die dicken Kerne besser auszulasten.

Wohin die Last für zukünftige KI/NN-Anwendungen wandert, steht auch noch in den Sternen: Aktuell hauptsächlich in der Cloud scheint es sich auf die lokalen Geräte zu verlagern. Bei Intel mittels VNNI in die CPU, bei ARM auf eine eigene Unit im SoC, bei AMD und NV in die GPUs.

Gast
2021-07-29, 14:19:20
Ich sehe ein Problem bei dem ganzen, und zwari wie festgestellt wird, wo was laufen soll.
Bei Android usw. erstellen die Hersteller Profile, nicht unoft mit Benchmarks auf den Perf-Cores und alles andere auf den Spar-Cores.

Wie soll das auf dem Desktop funktionieren? Klar, Edge, Chrome, Office, Photoshop bekommen von MS Profile. Aber was ist mit all den anderen Anwendungen? Was ist mit Spielen?

Ein Spiel kann 30 Threads haben, wovon weniger sehr Zeitkritisch sind, andere z.B. Streaming, laufen viel mehr, sind aber weniger kritisch.