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/