News Intel Core Ultra 200S im Detail: IPC-Analyse der P- und E-Cores vs. Raptor Lake und Zen 5

[foofoobar]

Ja und Nein. Instructions per Clock ist ein etwas "dehnbarer" Begriff, weil es keine einheitliche Messmethode gibt.

Sieht man sich Zen 5 an, dann kann Zen 5 theoretisch 16 Befehle zur gleichen Zeit ausführen, bei Lion Cove sind es bis zu 18 Befehle. Davon sind aber manche "INT", andere "VEC" und wieder andere Load/Store-Anweisungen.

Deswegen ging man mit der Zeit über, die IPC anhand von Programmen zu ermitteln, in denen kommen aber die Befehle in unterschiedlichen Schwerpunkten zum Tragen. Man kann mit dem gleichen Programm aber zwischen verschiedenen Architekturen unterscheiden und der IPC-Begriff hat sich mit der Zeit dafür durchtgesetzt.

Man kann das durchaus vernünftig messen, dafür braucht man keine Quirks oder Hacks:

$ for i in 1 5 9; do perf stat -e cpu-cycles,instructions gzip -$i < testfile > /dev/null; done

 Performance counter stats for 'gzip -1':

     3.078.415.386      cpu-cycles                                                            
     5.361.757.187      instructions                     #    1,74  insn per cycle            

       0,580785922 seconds time elapsed

       0,572794000 seconds user
       0,008011000 seconds sys



 Performance counter stats for 'gzip -5':

     5.980.479.913      cpu-cycles                                                            
     8.957.503.177      instructions                     #    1,50  insn per cycle            

       1,120695668 seconds time elapsed

       1,114718000 seconds user
       0,006003000 seconds sys



 Performance counter stats for 'gzip -9':

    15.553.787.857      cpu-cycles                                                            
    19.718.162.236      instructions                     #    1,27  insn per cycle            

       2,927111434 seconds time elapsed

       2,920126000 seconds user
       0,006997000 seconds sys


$ for i in 1 5 9; do echo "############ $i"; perf stat -e cpu-cycles,instructions gzip -d < c-$i.gz > /dev/null; done
############ 1

 Performance counter stats for 'gzip -d':

     9.447.502.478      cpu-cycles                                                            
    17.998.312.402      instructions                     #    1,91  insn per cycle            

       1,771316906 seconds time elapsed

       1,759310000 seconds user
       0,011995000 seconds sys


############ 5

 Performance counter stats for 'gzip -d':

     8.953.804.801      cpu-cycles                                                            
    16.601.350.730      instructions                     #    1,85  insn per cycle            

       1,677399493 seconds time elapsed

       1,662395000 seconds user
       0,015003000 seconds sys


############ 9

 Performance counter stats for 'gzip -d':

     8.830.464.552      cpu-cycles                                                            
    16.328.793.671      instructions                     #    1,85  insn per cycle            

       1,654667908 seconds time elapsed

       1,627686000 seconds user
       0,026994000 seconds sys


$

BTW: Unter Linux kann lassen auch Cores/Threads recht einfach online raus und wieder rein nehmen. So würden sich auch die verschiedenen Core Typen wunderbar vermessen lassen.

 

[G3cko]

IPC Vergleich und dann keinen Singlethread-Test?

 

[zeedy]

@Jan warum fehlt eigentlich der Verbrauch eines Zen5 Kerns bei 4 Ghz? 🤔

 

[fox40phil]

Wieso nicht wieder L4 Cache einführen und evtl wieder effizient vorne mitspielen?! Sie waren darin Vorreiter….
Unglaublich, dass sie da nichts tun.

Ach so, wieso hat man hier in dem Artikel später plötzlich den 9950x abtreten lassen?! Und nicht den 8 Kerner mit SMT?! VS Intels 8p-Kerner ohne HT?

 

[MaverickM]

Beides geht aus dem Test überhaupt nicht hervor.

Aeh, doch, tut es. Man muss nur lesen.

 

[TechFA]

Stromverbrauch der Kerne

Interessant ist abschließend der Blick auf den Verbrauch

Ja! Insbesondere aber, weil seitens Intel mit Effizienz geworben wird, wäre eine tatsächlich tiefgründige Detailanalyse über den Stromverbrauch in der Tat nicht nur absolut gern gesehen, sondern in diesem Fall auch mehr als geboten.

Wie @Booby bereits erwähnte: Es besteht der akute Verdacht hat den Hintergrund, daß Intel oder zumindest Board-Partner bei den tatsächlichen Stromverbrauchswerten für Arrow Lake vorsätzlich geschummelt haben. Und ja, es besteht kein Zweifel dran, daß dies unbeabsichtigt geschehen ist. Denn es ist schlichtweg unmöglich, dass es sich hier um ein "Versehen" handelt.

Denn sowohl Steve Walton von Hardware Unboxed als auch Steve Burke von Gamers Nexus zufolge, ziehen die Arrow Lake-CPUs zumindest auf dem Mainboard Asus ROG Maximus Z890 Hero zwischen +50-60 Watt über den 24-poligen ATX-Anschluss, anstatt gemäß der ATX-norm konform, die CPU ausschließlich über die dedizierten 12-Volt EPS12V-Buchsen zu versorgen.

Dadurch wird der “Stromverbrauch” gezielt verkleinert – Arrow Lake wird viel effizienter dargestellt, als es tatsächlich ist.

Weil 4 Phasen der VRMs auf dem Maximus Z890 Hero explizit nicht elektrisch von den Leitungen der EPS12V-Stecker gespeist, sondern ausschließlich über den 24-Pin ATX-Stecker versorgt werden. Es findet daher ganz gezielt ein Power-routing statt, womit die tatsächlich gemessene Package-Power sinkt, und die Verbrauchswerte der CPU (Package-Power) werden künstlich kleingehalten.
Dieses abartige (i.S.v. nicht der normalen Art und Wiese entsprechend und nicht Standard-konform) Power-Routing, ist seitens der Asus-Entwickler gegenüber Steve Burke von Gamers Nexus auch einwandfrei bestätigt worden.

Das besagte Asus-Mainboard ROG Maximus Z890 Hero war aber die Grundlage Eures gesamten Testberichts, womit sämtliche ermittelten Verbrauchswerte (Package-Power) für ARL, zumindest auf dem besagten Mainboard, vollkommen wertlos sind.

Es ist leider eine absichtliche elektrische Verschiebung und gezielte Umleitung der Verbrauchswerte der CPU (vorsätzlich, mit Täuschungsabsicht), um Intel's Arrow Lake-CPUs deutlich effizienter aussehen zu lassen, als sie es in Wirklichkeit sind.

“Now for the power-consumption data; And this section of the review caused some headaches, but thanks to Steve from Gamers Nexus, I was able to catch the issue with this testing – So thank Steve, and make sure you go watch his review! They have loads of really great power-data.

But in short The Story Goes Like This: The ROG Maximus Z890 Hero does something rather unique. Instead of feeding all of the power to the CPU through the Dual-EPS 12 Volt-rails, as you would typically find on a motherboard, 4 of the vCore power-stages are connected via the 24-pin ATX power-cable!

Unaware of this, I was very confused as to how the 285k with a 250 Watt-limit was drawing just 196 Watts.

That was until Gamers Nexus Steve alerted me to the fact, that around 50–60 Watt of the power to the CPU, was being delivered via the 24-pin ATX power-cable – This had been confirmed by Asus' Engineers.

So after a retest using the MSI Meg z890 UniFy X, I was able to confirm the correct EPS 12-Volt data, which sees the 285k consume 258 Watts in this test.” – Steve Walton, Hardware Unboxed

Im Hinblick des Ganzen ist es dann auch nicht wirklich verwunderlich, daß ein großer Teil der Rezensenten und Outlets (Gamers Nexus, Hardware Unboxed, TechPowerUp, HardwareLuxx, ComputerBase usw.) für ihre Rezensionen das besagte Asus-Motherboard geliefert bekommen hat ... Schande über den, der Böses dabei denkt!

Also einfach +50W zu jeder Bewertung der "Stromverbrauchstests" hinzuaddieren, und man stellt schnell fest, daß ARL nicht einmal im Entferntesten so effizient ist, wie es in den Tests dargestellt wird.

 

[Hovac]

Aeh, doch, tut es. Man muss nur lesen.

Nur bei genau 4 GHz, da laufen die Kerne aber praktisch nie, daher eben nicht. Man kann es nicht einfach linear hochrechnen.

 

[mae]

BTW: Unter Linux kann lassen auch Cores/Threads recht einfach online raus und wieder rein nehmen. So würden sich auch die verschiedenen Core Typen wunderbar vermessen lassen.

Nicht nur das, man kann auch Prozesse an bestimmte Kerne oder Gruppen von "CPUs" (Hardware-Threads bzw. Kerne) zuweisen:

taskset -c 2 perf stat -e cpu-cycles,instructions gzip -9 < testfile > /dev/null

laesst perf und seine Kinder (also gzip) auf "CPU" 2 laufen. Jetzt muss man nur noch wissen, welche "CPU" was ist. Ich lese das aus /proc/cpuinfo heraus (hier fuer einen Core i3-1315U):

processor       : 0
...
core id         : 0
...

processor       : 1
...
core id         : 0
...

processor       : 4
...
core id         : 12
...

processor       : 5
...
core id         : 13
...

Hier sieht man, dass "processor 0" und "processor 1" auf dem selben Kern "core id 0" laufen. Das sind also die beiden Hardware-Threads eines P-Cores. Im Gegensatz dazu gibt's die "core id 12" von "processor 4" nur einmal, das ist also ein E-Core. Bei den neuen Prozessoren gibt's kein SMT, da geht diese Methode nicht. Man kann aber z.B. schauen, wieviel MHz der Kern erreicht, oder wie gross die caches sind. Und zumindest mit perf 6.2.16 zeigt perf auch an, auf welcher Art von core z.B. die cycles gemessen wurden:

[alderlake:~:110114] taskset -c 0 perf stat -e cycles true

 Performance counter stats for 'true':

            796829      cpu_core/cycles/                                                      
     <not counted>      cpu_atom/cycles/                                                        (0.00%)

       0.001478569 seconds time elapsed

       0.001468000 seconds user
       0.000000000 seconds sys


[alderlake:~:110115] taskset -c 4 perf stat -e cycles true

 Performance counter stats for 'true':

     <not counted>      cpu_core/cycles/                                                        (0.00%)
           1022794      cpu_atom/cycles/                                                      

       0.001848495 seconds time elapsed

       0.001841000 seconds user
       0.000000000 seconds sys

true ist ein Programm, das nur den exit-status 0 zurueckgibt.

 

[foofoobar]

Nicht nur das, man kann auch Prozesse an bestimmte Kerne oder Gruppen von "CPUs" (Hardware-Threads bzw. Kerne) zuweisen:

taskset -c 2 perf stat -e cpu-cycles,instructions gzip -9 < testfile > /dev/null

Oder so. Viele Wege führen nach Rom.

[alderlake:~:110114] taskset -c 0 perf stat -e cycles true

 Performance counter stats for 'true':

            796829      cpu_core/cycles/                                                      
     <not counted>      cpu_atom/cycles/                                                        (0.00%)

       0.001478569 seconds time elapsed

       0.001468000 seconds user
       0.000000000 seconds sys


[alderlake:~:110115] taskset -c 4 perf stat -e cycles true

 Performance counter stats for 'true':

     <not counted>      cpu_core/cycles/                                                        (0.00%)
           1022794      cpu_atom/cycles/                                                      

       0.001848495 seconds time elapsed

       0.001841000 seconds user
       0.000000000 seconds sys

true ist ein Programm, das nur den exit-status 0 zurueckgibt.

Lass das doch mal mit gzip und den perf Parameter "e cpu-cycles,instructions" auf den beiden verschiedenen Cores laufen. Dann hätte man auch mal Werte für deine CPU(s), meine ist ein "AMD Ryzen 7 7700".

BTW: Schau dir mal "/sys/devices/system/cpu" an.

 

[incurable]

Es ist leider eine absichtliche elektrische Verschiebung und gezielte Umleitung der Verbrauchswerte der CPU (vorsätzlich, mit Täuschungsabsicht), um Intel's Arrow Lake-CPUs deutlich effizienter aussehen zu lassen, als sie es in Wirklichkeit sind.

Ach, und deshalb hat Intel in den Folien den Gesamtverbrauch des Systems als Basis für Vergleiche verwendet. 🤷‍♂️

https://pics.computerbase.de/1/1/4/4/5/0-0e461b78be18e58f/21-1080.e77d5ab3.png
https://www.computerbase.de/artikel/prozessoren/intel-arrow-lake-s-core-ultra-200s-details.89465/

 

[mae]

Lass das doch mal mit gzip und den perf Parameter "e cpu-cycles,instructions" auf den beiden verschiedenen Cores laufen. Dann hätte man auch mal Werte für deine CPU(s), meine ist ein "AMD Ryzen 7 7700".

Der input ist fuer coreutils 8.32, die Cores sind Golden Cove, Gracemont, und Zen3:

[alderlake:~:110153] zcat /usr/share/info/coreutils.info.gz|taskset -c 0 perf stat -e cycles,instructions gzip -9 >/dev/null

 Performance counter stats for 'gzip -9':

         253776422      cpu_core/cycles/                                                      
     <not counted>      cpu_atom/cycles/                                                        (0.00%)
         301032109      cpu_core/instructions/                                                
     <not counted>      cpu_atom/instructions/                                                  (0.00%)

       0.075011912 seconds time elapsed

       0.075019000 seconds user
       0.000000000 seconds sys


[alderlake:~:110154] zcat /usr/share/info/coreutils.info.gz|taskset -c 4 perf stat -e cycles,instructions gzip -9 >/dev/null

 Performance counter stats for 'gzip -9':

     <not counted>      cpu_core/cycles/                                                        (0.00%)
         311231781      cpu_atom/cycles/                                                      
     <not counted>      cpu_core/instructions/                                                  (0.00%)
         301096593      cpu_atom/instructions/                                                

       0.124828005 seconds time elapsed

       0.124844000 seconds user
       0.000000000 seconds sys

[c8:~:110116] zcat /usr/share/info/coreutils.info.gz|taskset -c 4 perf stat -e cycles,instructions gzip -9 >/dev/null

 Performance counter stats for 'gzip -9':

         259339857      cycles                                                      
         299878825      instructions              #    1.16  insn per cycle         

       0.077504345 seconds time elapsed

       0.077520000 seconds user
       0.000000000 seconds sys

P.S.: Auf der Maschine alderlake laeuft Ubuntu 22.04, auf c8 Debian 11, jeweils mit den zugehoerigen gzip-Binaries, das erklaert vielleicht die Abweichung bei den instructions. In beiden Faellen ist die Info-Datei fuer coreutils dieselbe.

 

[TechFA]

Ach, und deshalb hat Intel in den Folien den Gesamtverbrauch des Systems als Basis für Vergleiche verwendet. 🤷‍♂️

Wer redete denn bitte von Intel hier? Von Intel selbst redete ich mit keiner Silbe!

Steve (Gamers Nexus) hatte seinerseits in dem Hin und Her wegen diesem Problem (der aufgeteilten Verbrauchsaufteilung zwischen EPS12V und ATX12V) mit Intel gefragt, ob andere OEMs das auch so handhaben würden. Intel meinte sinngemäß, daß ihnen das Problem bis dato nicht bekannt gewesen ist und auch, daß sie keine Kenntnis darüber hätten, ob Hauptplatinen anderer OEMs ebenso verfahren würden.

Und ich glaube das Intel sogar, daß Intel die Verdrahtung der Hauptplatine nicht gewußt hat, falls sie für die eigenen innerbetrieblichen Messungen überhaupt Hauptplatinen von ASUS genutzt haben (und nicht von anderen Herstellern). Dafür gibt es nämlich auch keinerlei Belege! Intel muß sich auch nicht im Geringsten für die Verdrahtung der Boards durch die OEMs überhaupt interessiren …

Kann gut sein, daß Intel sich bei den Messungen selbst auf die Package-Power verlassen oder gleich Stromzangen (Zange-Ampere-Meter) genutzt haben. Kann sein, daß sie die eigenen Messungen auf MSI, Gigabyte oder AsRock-Hauptplatinen gemacht haben …

Der Punkt ist, es geht hier nicht um Intel, es geht um ASUS und ihre Mainboards – Steve hat gemeint, daß das Problem wohl bei einigen ASUS-Mainboards besteht. Andere OEMs haben das Problem jedenfalls nicht.

Ich habe nur aufzeigen wollen, daß eben diese ASUS Hauptplatine (ROG Maximus Z890 Hero) vonseiten ASUS' augenscheinlich explizit so entwickelt wurde, um ein Teil des Verbrauchs an den Messgeräten vorbei zu schleusen, besser gegenüber anderen OEMs dazustehen und am Tag der Vorstellung (Launch-Day) die Reviews für sich zu gewinnen.

Ist ja nicht das erste Mal, daß Asus mit irgendwas vorprescht, um in Tests deutlich besser wegzuukommen (resultiert in erhöhten Verkaufszahlen!) – Kam Multi Core Enhancement damals nicht ebenso von ASUS?!

Der Punkt ist, daß allein ASUS hier der schwarze Peter zuzuschieben ist, nicht Intel!
Und das war auch definitiv kein Versehen, das war eindeutig Absicht, weil 4 Spannungswandler für die vCore-Spannung der CPUs explizit als ATX12V auf den großen 24-poligen ATX-Stecker gelegt und galvanisch von dedizierten EPS12V für die CPU getrennt wurden.

Hauptplatinen anderer Hersteller haben das Problem ja nicht und zeigen die realen Verbrauchswerte an.

---

TechPowerUp hat deswegen mit dem MSI Z890 Carbon die (richtigen) Verbrauchswerte ermittelt.

The ASUS Z890 Hero motherboard feeds four of the CPU VRM phases from the 24-pin ATX connector, instead of the 8-pins, which makes it impossible to measure CPU-only power with dedicated test equipment (we're not trusting any CPU software power sensors). You either lose some power because only the two 8-pin CPU connectors are measured, or you end up including power for the GPU, chips, and storage when measuring the two 8-pin connectors along with the 24-pin ATX. For this reason, we used an MSI Z890 Carbon motherboard exclusively for the power consumption tests in this review.

Quelle: TechPowerUp.com Intel Core Ultra 9 285K Review - Application Power Consumption

HardwareLuxx ist sich des Problems mit dem (im Test verwendeten) ASUS ROG Maximus Z890 Hero ebenfalls bewußt, und weist entsprechend auf die Problematik hin.

Auf einen speziellen Punkt im Zusammenhang mit dem ASUS ROG Maximus Z890 Hero wollen wir noch eingehen: Die Strom- und Spannungsversorgung des Prozessors erfolgt nicht mehr ausschließlich über die beiden EPS-Anschlüsse, sondern in bestimmten Konstellationen auch über den ATX-24-Pin. Damit werden Messungen der Leistungsaufnahme über die EPS-Anschlüsse schwierig bzw. ungenau. Diese Aufteilung der Versorgung erfolgt in dieser Form aber nur auf Mainboards von ASUS, denn auf Nachfrage sagte Intel, dass dies keine Vorgabe sei. Nur ASUS habe dies so umgesetzt und man habe bei Intel auch erst kürzlich davon erfahren.

Quelle: HardwareLuxx.de Intel Core Ultra 200S alias Arrow Lake im Test - Ein Start mit Hürden (Das ASUS ROG Maximus Z890 Hero)

Hardware Unboxed, dessen Stellungnahme ich ja vorher schon erwähnte, haben stattdessen (nachdem man wußte, woran es lag; durch Gamers Nexus' explizite Messungen) für sämtliche Verbrauchsmessungen das MSI MEG Z890 UNIFY-X benutzt.

Wie gesagt, es geht um ASUS' Boards, nicht per se um Arrow Lake!
Durch das verwendete ROG Maximus Z890 Hero von ASUS, sind aber leider ComputerBase' Messungen fehlerhaft und stellen den Prozessor (oder die gesamte Plattform) als solches bedauerlicherweise deutlich effizienter als tatsächlich gegeben dar. Dafür kann CB hier aber nicht einmal was!

 

[Jan]

Wir haben den Verbrauch aber (anders als bei Grafikkarten) nicht an zuführenden Kabeln gemessen, sondern die Telemetrie der CPU per HWiNFO ausgelesen. Mein Kenntnisstand ist, dass das passt - und wir haben doch auch Berbräuche jenseits von 220 Watt im Durchschnitt und beim 285K bis 263 Watt maximal - da fehlen keine 50 Watt bis 250 MTP.

?

Grüße aus UK btw.

 

[stefan92x]

@Jan selber messen ist grundsätzlich besser, als auf HWinfo zu vertrauen, aber in diesem Fall gebe ich dir recht. Falls bei euren Werten was nicht passt, dann weil die CPU selber nicht präzise misst (was durchaus möglich ist). Aber für dieses Gefrickel von Asus seid ihr dadurch nicht empfänglich, die CPU kann ja gar nicht feststellen, woher sie ihren Strom bekommt.

 

[Katharsas]

Arrow Lake-S bietet kein Hyper-Threading auf den P-Cores mehr. Das sei in Anbetracht der stärkeren E-Cores nicht mehr notwendig, so Intel.

Diese Aussage von Intel ist zu 99% Marketing-Bullshit.

HT erlaubt es, "breite" Kerne in der Architektur zu haben, welche nur von wenigen Thread-Workloads wirklich zu 100% ausgelastet werden können, ohne dann bei den anderen Threads massiv an Effizienz zu verlieren.

Damit erhöht man also massiv die Möglichkeit, mit einem Kern-Design sehr unterschiedliche Workloads sehr effizient auszuführen.

Solange Betriebssystem nicht eine weitreichende Fähigkeit erhalten, zu verstehen, welcher Thread auf welchem Kern am effizientesten laufen wird (vorausgesetzt dass die CPU überhaupt Kerne mit unterschiedlicher Architektur-Spezialisierung hat), und solange wir weiterhin eine sehr heterogene/unterschiedliche Applikations-Landschaft haben wird HT ein riesieger Vorteil bleiben.

 

[mae]

Diese Aussage von Intel ist zu 99% Marketing-Bullshit.

HT erlaubt es, "breite" Kerne in der Architektur zu haben, welche nur von wenigen Thread-Workloads wirklich zu 100% ausgelastet werden können, ohne dann bei den anderen Threads massiv an Effizienz zu verlieren.

Diese Aussage ist vom SMT-Marketing inspirierter Bullshit. 100% Auslastung gibt's in realen Anwendungen nicht, und sowohl Intel's Lion Cove und Skymont, als auch ARM's Cortex-X4, Apple's M1-M4, und Qualcomm's Oryon zeigen, dass Computerarchitekten keine Erlaubnis von SMT-Fans brauchen, um breite Kerne zu bauen.

Schauen wir einmal, was SMT bei dem gzip-Beispiel aus #71 bringt, wo der Kern ohne SMT wirklich schlecht ausgelastet wird. Aufruf mit

zcat /usr/share/info/coreutils.info.gz >coreutils.info
for i in 2 3; do taskset -c $i sh -c "for j in 1 2 3; do perf stat -r100 -e cycles,instructions gzip -9 -c coreutils.info >/dev/null; done" 2>log$i& done; wait
#oder statt "2 3" nur "0" oder "4"

Dabei ergeben sich die folgenden Zyklenzahlen fuer die 301M Befehle in den verschiedenen Aufrufen (jeweils das mittlere der drei Resultate, damit auch sicher die ganze Zeit SMT im Spiel ist):

cycles    IPC
252929987 1.19 processor 0 (P-Core (Golden Cove) ohne SMT)
306006448 0.98 processor 2 (P-Core (Golden Cove), SMT mit 3)
305512406 0.99 processor 3 (P-Core (Golden Cove), SMT mit 2)
311253047 0.97 processor 4 (E-Core (Gracemont))

Fuer den Core mit processor 2 und 3 ergibt das zusammen IPC=1.97, und das ist richtig gut (meine bisherigen Erfahrungen mit SMT waren eher ernuechternd, bis hin zu schlechterem Durchsatz durch SMT); natuerlich ist jeder Thread immer noch langsamer als ohne SMT, aber in diesem Fall nicht so schlimm wie in jedem anderen Fall, den ich gesehen habe. Allerdings kostet die hoehere Auslastung auch Strom. Ich bin aber im Moment zu faul, das auch noch zu messen, aber im Artikel stand ja schon, dass der Stromverbrauch aehnlich steigt wie der Durchsatz (zumindest bei Cinebench). Und warum das dazu fuehren kann, dass man vielleicht lieber auf SMT verzichtet, habe ich in #50 beschrieben.

Solange Betriebssystem nicht eine weitreichende Fähigkeit erhalten, zu verstehen, welcher Thread auf welchem Kern am effizientesten laufen wird (vorausgesetzt dass die CPU überhaupt Kerne mit unterschiedlicher Architektur-Spezialisierung hat), und solange wir weiterhin eine sehr heterogene/unterschiedliche Applikations-Landschaft haben wird HT ein riesieger Vorteil bleiben.

Eher im Gegenteil: Nur wenn das Betriebssystem versteht, welche Charakteristik die Programme haben, kann es die richtige Abwaegung zwischen Latenz (wenn das wichtig ist, kein SMT) und Durchsatz (SMT) treffen. Und ohne dieses Wissen entscheidet sich Intel im Arrow Lake S fuer Latenz.

 

[incurable]

Allerdings kostet die hoehere Auslastung auch Strom. Ich bin aber im Moment zu faul, das auch noch zu messen, aber im Artikel stand ja schon, dass der Stromverbrauch aehnlich steigt wie der Durchsatz (zumindest bei Cinebench). Und warum das dazu fuehren kann, dass man vielleicht lieber auf SMT verzichtet, habe ich in #50 beschrieben.

Höhere Auslastung kostet nur Iso-Takt zusätzlichen Strom. Iso-Leistung betrachtet kann der Takt (und damit Spannung und unterm StrIch Verbrauch) aber sinken, was zu weniger Joule pro Leistungseinheit führt. (vulgo: Effizienz erhöht)

Ergänzung (26. Oktober 2024)

Der Punkt ist, daß allein ASUS hier der schwarze Peter zuzuschieben ist, nicht Intel!

Problem: Es gibt gar keinen schwarzen Peter. Nichts wird verheimlicht, alles ist einwandfrei mess- und nachvollziehbar.

 

[mae]

Höhere Auslastung kostet nur Iso-Takt zusätzlichen Strom. Iso-Leistung betrachtet kann der Takt (und damit Spannung und unterm StrIch Verbrauch) aber sinken, was zu weniger Joule pro Leistungseinheit führt. (vulgo: Effizienz erhöht)

Wenn alle Kerne gleich waeren, dann koennte das so sein. Auf einem Arrow Lake S hast Du aber Kerne, die bei gleichem Takt effizienter sind als andere. Wenn Du jetzt SMT dazugibst, und dann einen groesseren Anteil der Arbeit auf den ineffizienteren Kernen machst, und das dann wieder mit niedrigerem Takt ausgleichst, ist der Durchsatz am Ende hoeher oder vielleicht sogar niedriger? Intel meint offenbar, dass sich das nicht auszahlt, abgesehen davon, dass dadurch die Latenzen von Latenzempfindlichen Threads steigen.

P.S.: Vom Marketing her waere es besser gewesen, SMT beizubehalten. Da braucht man dann nicht viel erklaeren, und kann mit genausovielen Threads protzen wie die Konkurrenz.

 

[incurable]

Wenn das in der Aufgabenverteilung zu kompliziert sein sollte, wäre das eher ein Argument gegen heterogene Kernkombinationen als gegen SMT.

 

[RogueSix]

Solange Betriebssystem nicht eine weitreichende Fähigkeit erhalten, zu verstehen, welcher Thread auf welchem Kern am effizientesten laufen wird (vorausgesetzt dass die CPU überhaupt Kerne mit unterschiedlicher Architektur-Spezialisierung hat), und solange wir weiterhin eine sehr heterogene/unterschiedliche Applikations-Landschaft haben wird HT ein riesieger Vorteil bleiben.

Soweit ich das verstanden habe, spielt das OS bei Intel CPUs schon lange prinzipiell zweite Geige, weil in erster Linie der Hardware Scheduler a.k.a Thread Director (seit der 12th gen, also Alder Lake) bestimmt, welcher Thread wo landet.

Der Thread Director wurde jede Gen weiter entwickelt (auch in enger Abstimmung mit M$ zwecks optimierten Zusammenspiels mit dem Win 11 Scheduler) und da ist es inzwischen meines Wissens nach so, dass bei Arrow Lake jeder Thread zunächst mal auf einem E-Core startet und der Thread Director dann fallweise entscheidet, ob der Thread zu einem P-Core weiter/höher "eskaliert" wird oder ob der E-Core genügt.

Insofern bin ich mir nicht sicher, ob das OS da allzu viel "verstehen" muss. Bei Intel zumindest ist für dieses Verständnis eher der Thread Director zuständig.