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

[Juri-Bär]

Für EddyNoGamer und OttoNichtVideobearbeiter bieten die alten E-Cores im N100 oder N97 genug Rechenleistung. Die ordnen sich so zwischen den i5 von vor 7 bis 11 Jahren ein bei beindruckend niedrigem Stromverbrauch.

Wenn die E-Cores nun nicht mehr bei 3,2 oder 3,4 GHz herumdümpeln, sondern 4,6 Ghz schaffen, sollten sie bei jetzt um 31% gesteigerter IPC im Singlethread etwa so schnell sein, wie die Vermeer-Prozessoren Zen3 (z.B. Ryzen 5 5600).
Ein Octacore mit nur E-Cores wäre also schon eine veritable Budget-Gamer-CPU, deren Stromverbrauch Freude aufkommen lassen würde.

 

[foofoobar]

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.

Ich hab das mal konventionell (Wall Clock) auf einem 8 Core Zen4 mit 65 Watt (Ryzen 7 7700) für gzip und alle Compresslevel durchgemessen:

$ cat ./do-bench.sh
#!/bin/bash
for filename in compressable not-compressable
do
    for level in $(seq 1 9)
    do
        echo on | sudo tee /sys/devices/system/cpu/smt/control > /dev/null
          ResSmt=$(export TimeLog=time.log; > $TimeLog; for i in $(seq 0 4); do /bin/time -a -o $TimeLog -f "%e real %U user %S sys" sh -c 'echo $(seq 0 127) | xargs -P 16 -n 1 sh -c "gzip -'$level' < '$filename' > /dev/null"' ; done; awk '{ i++; res += $1 } END { printf("%f\n", res / i) }' $TimeLog)

        echo off | sudo tee /sys/devices/system/cpu/smt/control > /dev/null
        ResNoSmt=$(export TimeLog=time.log; > $TimeLog; for i in $(seq 0 4); do /bin/time -a -o $TimeLog -f "%e real %U user %S sys" sh -c 'echo $(seq 0 127) | xargs -P  8 -n 1 sh -c "gzip -'$level' < '$filename' > /dev/null"' ; done; awk '{ i++; res += $1 } END { printf("%f\n", res / i) }' $TimeLog)

        export ResNoSmt ResSmt level filename
        awk 'BEGIN { printf("File: %20s Level: %2d NoSmtTime: %8.3f SmtTime: %8.3f LessFactor: %6.3f MoreFactor: %6.3f\n", ENVIRON["filename"], ENVIRON["level"], ENVIRON["ResNoSmt"], ENVIRON["ResSmt"], ENVIRON["ResSmt"] / ENVIRON["ResNoSmt"],  ENVIRON["ResNoSmt"] / ENVIRON["ResSmt"]) }'
    done
done
echo on | sudo tee /sys/devices/system/cpu/smt/control > /dev/null
$ ./do-bench.sh
File:         compressable Level:  1 NoSmtTime:    9.846 SmtTime:    7.138 LessFactor:  0.725 MoreFactor:  1.379
File:         compressable Level:  2 NoSmtTime:   10.604 SmtTime:    7.618 LessFactor:  0.718 MoreFactor:  1.392
File:         compressable Level:  3 NoSmtTime:   12.964 SmtTime:    8.642 LessFactor:  0.667 MoreFactor:  1.500
File:         compressable Level:  4 NoSmtTime:   13.758 SmtTime:    9.740 LessFactor:  0.708 MoreFactor:  1.413
File:         compressable Level:  5 NoSmtTime:   19.058 SmtTime:   12.952 LessFactor:  0.680 MoreFactor:  1.471
File:         compressable Level:  6 NoSmtTime:   27.176 SmtTime:   17.462 LessFactor:  0.643 MoreFactor:  1.556
File:         compressable Level:  7 NoSmtTime:   32.094 SmtTime:   20.204 LessFactor:  0.630 MoreFactor:  1.588
File:         compressable Level:  8 NoSmtTime:   43.686 SmtTime:   26.424 LessFactor:  0.605 MoreFactor:  1.653
File:         compressable Level:  9 NoSmtTime:   49.344 SmtTime:   29.348 LessFactor:  0.595 MoreFactor:  1.681
File:     not-compressable Level:  1 NoSmtTime:   17.608 SmtTime:   12.494 LessFactor:  0.710 MoreFactor:  1.409
File:     not-compressable Level:  2 NoSmtTime:   17.590 SmtTime:   12.718 LessFactor:  0.723 MoreFactor:  1.383
File:     not-compressable Level:  3 NoSmtTime:   17.812 SmtTime:   13.000 LessFactor:  0.730 MoreFactor:  1.370
File:     not-compressable Level:  4 NoSmtTime:   19.810 SmtTime:   14.404 LessFactor:  0.727 MoreFactor:  1.375
File:     not-compressable Level:  5 NoSmtTime:   20.166 SmtTime:   14.604 LessFactor:  0.724 MoreFactor:  1.381
File:     not-compressable Level:  6 NoSmtTime:   20.454 SmtTime:   14.774 LessFactor:  0.722 MoreFactor:  1.384
File:     not-compressable Level:  7 NoSmtTime:   20.808 SmtTime:   14.954 LessFactor:  0.719 MoreFactor:  1.391
File:     not-compressable Level:  8 NoSmtTime:   22.558 SmtTime:   15.672 LessFactor:  0.695 MoreFactor:  1.439
File:     not-compressable Level:  9 NoSmtTime:   23.530 SmtTime:   16.286 LessFactor:  0.692 MoreFactor:  1.445
$

compressable ist ein tarball mit C-Quellcode drin.
not-compressable ist ein PDF was nur aus Bildern besteht.

Für einen Intel müsste man wahrscheinlich das Script so modifizieren das einem die E-Kerne nicht dazwischen funken.
Also die Cores/Threads selektiv abschalten statt einfach SMT on/off zu schalten. (/sys/devices/system/cpu/cpux/online) und die Anzahl Threads die der xargs gleichzeitig laufen lässt (-P) anpassen.
Ich wäre an Ergebnissen von Intels interessiert.

Daher kann ich diese Zweifel an SMT einfach nicht nachvollziehen.
Gewinne in diesen Fall von einem Faktor von 1,38 bis 1,68 bei ein wenig mehr Chipfläche ?(5%)? für den eigentlichen Core sind doch super.

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.

Ein perfekter Scheduler müsste halt in die Zukunft schauen können. Ein Thread kann halt in der nächsten Zeitscheibe etwas völlig anderes tun.

EDIT/NACHTRAG:

Hier noch die Werte von einem Zen1:

$ lscpu | grep Ry
Model name:                      AMD Ryzen 7 1700X Eight-Core Processor
$ ./do-bench.sh
File:         compressable Level:  1 NoSmtTime:   19.448 SmtTime:   13.424 LessFactor:  0.690 MoreFactor:  1.449
File:         compressable Level:  2 NoSmtTime:   20.720 SmtTime:   14.128 LessFactor:  0.682 MoreFactor:  1.467
File:         compressable Level:  3 NoSmtTime:   24.214 SmtTime:   16.474 LessFactor:  0.680 MoreFactor:  1.470
File:         compressable Level:  4 NoSmtTime:   27.866 SmtTime:   18.572 LessFactor:  0.666 MoreFactor:  1.500
File:         compressable Level:  5 NoSmtTime:   36.370 SmtTime:   24.044 LessFactor:  0.661 MoreFactor:  1.513
File:         compressable Level:  6 NoSmtTime:   48.980 SmtTime:   31.640 LessFactor:  0.646 MoreFactor:  1.548
File:         compressable Level:  7 NoSmtTime:   56.322 SmtTime:   35.834 LessFactor:  0.636 MoreFactor:  1.572
File:         compressable Level:  8 NoSmtTime:   74.634 SmtTime:   46.072 LessFactor:  0.617 MoreFactor:  1.620
File:         compressable Level:  9 NoSmtTime:   86.750 SmtTime:   50.524 LessFactor:  0.582 MoreFactor:  1.717
File:     not-compressable Level:  1 NoSmtTime:   33.414 SmtTime:   22.546 LessFactor:  0.675 MoreFactor:  1.482
File:     not-compressable Level:  2 NoSmtTime:   33.758 SmtTime:   23.034 LessFactor:  0.682 MoreFactor:  1.466
File:     not-compressable Level:  3 NoSmtTime:   34.104 SmtTime:   23.274 LessFactor:  0.682 MoreFactor:  1.465
File:     not-compressable Level:  4 NoSmtTime:   37.684 SmtTime:   25.886 LessFactor:  0.687 MoreFactor:  1.456
File:     not-compressable Level:  5 NoSmtTime:   38.232 SmtTime:   26.086 LessFactor:  0.682 MoreFactor:  1.466
File:     not-compressable Level:  6 NoSmtTime:   38.844 SmtTime:   26.602 LessFactor:  0.685 MoreFactor:  1.460
File:     not-compressable Level:  7 NoSmtTime:   39.396 SmtTime:   26.738 LessFactor:  0.679 MoreFactor:  1.473
File:     not-compressable Level:  8 NoSmtTime:   41.486 SmtTime:   28.028 LessFactor:  0.676 MoreFactor:  1.480
File:     not-compressable Level:  9 NoSmtTime:   43.446 SmtTime:   29.198 LessFactor:  0.672 MoreFactor:  1.488
$

 

[mae]

Ich wäre an Ergebnissen von Intels interessiert.

Stell die Eingabedateien zur Verfuegung, dann gerne.

Daher kann ich diese Zweifel an SMT einfach nicht nachvollziehen.

In dem von Dir zitiereten Teil habe ich klare Falschaussagen als solche kritisiert.

1) 100% Auslastung kann es gar nicht geben, weil es schon viel mehr ports zu functional units gibt als Befehle pro Zyklus aus dem register renamer herauskommen. Daher werden im Durchschnitt mindestens ein Teil der functional units brachliegen, selbt wenn man ein Programm zur maximalen Auslastung schreibt. Und bei realen Programmen ist die Auslastung noch geringer. Auch mit SMT. In der Messung von 2 parallelen gzip -9 auf einem Golden Cove mit eingeschaltetem SMT gab's z.B. einen IPC von 1.97, wobei Golden Cove bis zu 6 Befehle pro Zyklus im Register renamer verarbeiten kann; also nicht einmal der wird mit SMT zu 100% ausgelastet, und das ist der Teil, der noch am ehesten voll ausgelastet werden kann.

2) Die Aussage, dass SMT breite Kerne erlaube, wird durch die Existenz von breiten Kernen ohne SMT widerlegt.

Gewinne in diesen Fall von einem Faktor von 1,38 bis 1,68 bei ein wenig mehr Chipfläche ?(5%)? für den eigentlichen Core sind doch super.

Ja, ich war positiv ueberrascht davon, wie stark gzip -9 von SMT profitiert. Die Frage ist, inwieweit das bei etwas wie dem Arrow Lake S auch so waere, wenn man alle Kerne benutzt, eben aufgrund der Effizienzunterschiede zwischen P- und E-Cores und des Power Limits.

Als Beispiel, wo SMT nicht so gut funktioniert (aber wenigstens in diesem Versuch keine Verlangsamung bewirkt, das habe ich auch schon gesehen): Matrixmultiplikation von 2000x2000-Matrizen mit libblas (parallelisiert) mit dem binary http://www.complang.tuwien.ac.at/anton/lvas/effizienz/matmul/blas

[alderlake:~/pub/anton/lvas/effizienz/matmul:110306] OMP_NUM_THREADS=1 taskset -c 2 perf stat -e cycles,instructions blas 2000

 Performance counter stats for 'blas 2000':

        3693727569      cpu_core/cycles/                                                      
     <not counted>      cpu_atom/cycles/                                                        (0.00%)
       13829467057      cpu_core/instructions/                                                
     <not counted>      cpu_atom/instructions/                                                  (0.00%)

       1.281052670 seconds time elapsed

       0.922867000 seconds user
       0.079216000 seconds sys


[alderlake:~/pub/anton/lvas/effizienz/matmul:110307] OMP_NUM_THREADS=2 taskset -c 2,3 perf stat -e cycles,instructions blas 2000

 Performance counter stats for 'blas 2000':

        7580548310      cpu_core/cycles/                                                      
     <not counted>      cpu_atom/cycles/                                                        (0.00%)
       14884344008      cpu_core/instructions/                                                
     <not counted>      cpu_atom/instructions/                                                  (0.00%)

       1.254378354 seconds time elapsed

       1.836498000 seconds user
       0.188461000 seconds sys


[alderlake:~/pub/anton/lvas/effizienz/matmul:110308] OMP_NUM_THREADS=2 taskset -c 0,2 perf stat -e cycles,instructions blas 2000

 Performance counter stats for 'blas 2000':

        4192277066      cpu_core/cycles/                                                      
     <not counted>      cpu_atom/cycles/                                                        (0.00%)
       14966618139      cpu_core/instructions/                                                
     <not counted>      cpu_atom/instructions/                                                  (0.00%)

       0.809663063 seconds time elapsed

       0.978463000 seconds user
       0.156393000 seconds sys


[alderlake:~/pub/anton/lvas/effizienz/matmul:110309] OMP_NUM_THREADS=4 taskset -c 0-3 perf stat -e cycles,instructions blas 2000

 Performance counter stats for 'blas 2000':

        8650085151      cpu_core/cycles/                                                      
     <not counted>      cpu_atom/cycles/                                                        (0.00%)
       16544461470      cpu_core/instructions/                                                
     <not counted>      cpu_atom/instructions/                                                  (0.00%)

       0.803633158 seconds time elapsed

       1.907484000 seconds user
       0.415017000 seconds sys

Relevant sind hier die "elapsed"-Werte: In der ersten und zweiten Ausgabe wird ein Kern verwendet, ohne und mit SMT; SMT steigert hier die Geschwindigkeit um immerhin den Faktor 1.02; wobei die Parallelverarbeitung auch Overhead bringt, wie man an den instructions sieht; dieser Overhead wird immerhin durch SMT mehr als kompensiert. In der dritten und vierten Ausgabe werden zwei Kerne verwendet, ohne und mit SMT. SMT steigert hier die Geschwindigkeit um den Faktor 1.01 (wobei hier SMT ebenfalls Overhead durch die Parallelisierung kompensiert). Die Verwendung von zwei Kernen gegenueber einem, jeweils ohne SMT steigert die Geschwindigkeit um den Faktor 1.58 (wobei auch hier Overhead kompensiert wird). Das ganze auf einem Core i3-1315U.

 

[foofoobar]

Stell die Eingabedateien zur Verfuegung, dann gerne.

Nimm irgendwas von deiner Platte, irgendeinen Tarball mit C-Code in geeigneter Größe, ggf. mit dd zurecht schnippeln. Das von mir genutzte pdf wurde mit "img2pdf *.jpg *.jpg -o not-compressable" gebaut.
Die Files sollten lediglich so groß sein das die Laufzeiten lang genug sind bzw. ähnlich zu meinen.
Hint:

$ du -h not-compressable compressable
70M    not-compressable
100M    compressable
$

Da es um das Verhältnis geht sollten die konkreten Files keine signifikante Rolle spielen.

BTW:

Die Anzahl Jobs ("echo $(seq 0 127)") sollte ein vielfaches der Anzahl der Threads sein. (Ich habe 16 angenommen), damit zum Schluss noch genügend Jobs zum gleichzeitigen laufen übrig sind, damit keine Threads leer bleiben.
192 (16*12 oder ein vielfaches des KGV von 16 und 12) wäre ein besserer Wert als 128 um auch 4, 6, 8, 12, 16 Cores abzudecken.

Man könnte auch mit "cat /usr/bin/* | dd bs=1M count=100 > middle-compressable" noch was zwischen sehr gut komprimierbar und schlecht komprimierbar hinzufügen.

 

[foofoobar]

Auf Zen4 verliert das "blas" binary bei SMT: (Was auch immer das Ding im Detail anstellt)

$ OMP_NUM_THREADS=8 perf stat -e cycles,instructions ./blas 8000

 Performance counter stats for './blas 8000':

   167.525.670.925      cycles                                                               
   799.283.418.100      instructions                     #    4,77  insn per cycle           

       4,786359962 seconds time elapsed

      32,511036000 seconds user
       1,806890000 seconds sys


$ OMP_NUM_THREADS=8 perf stat -e cycles,instructions ./blas 8000

 Performance counter stats for './blas 8000':

   167.794.106.326      cycles                                                               
   799.265.962.778      instructions                     #    4,76  insn per cycle           

       4,805119623 seconds time elapsed

      32,614379000 seconds user
       1,785911000 seconds sys


$ OMP_NUM_THREADS=16 perf stat -e cycles,instructions ./blas 8000

 Performance counter stats for './blas 8000':

   362.888.104.039      cycles                                                               
   806.965.600.200      instructions                     #    2,22  insn per cycle           

       5,337126939 seconds time elapsed

      71,784595000 seconds user
       4,082261000 seconds sys


$ OMP_NUM_THREADS=16 perf stat -e cycles,instructions ./blas 8000

 Performance counter stats for './blas 8000':

   361.611.207.279      cycles                                                               
   806.538.063.040      instructions                     #    2,23  insn per cycle           

       5,314275721 seconds time elapsed

      71,674395000 seconds user
       3,995799000 seconds sys


$

 

[BAR86]

Wie groß ist jetzt eigentlich "ein" 285er Chip(220mm?) und aus wie vielen Chiplets (5?)besteht er?
Ich frag' mich, weil: einige der Probleme kommen durch Packaging/Interconnects die zu Latenzen und Stromverbrauch führen...
Wie würde sich hier wohl ein Monolith schlagen? Etwa ein reiner 8 Kerner aus P Cores in der Intel 3 oder oder TSMC N3E Fertigung... Oder gleich ein 16Kerner... Wie groß ist denn der 8P Kern Chiplets?

Rein hypothetisch könnte man ja sowas wie Bartlett Lake bringen, aber mit modernen Cores und Prozess, fast alle waren glücklich

 

[Tharan]

big little ist doch bei AMD in planung, oder irre ich mich da`?

Nein. Es ist bei AMD immer der gleiche Kern, aber mit mehr oder weniger Cahce direkt am Kern, womit die Kerndichte größer wird, die Taktung aber geringer zwecks Abwärme. Es ist somit nicht direkt mit big little vergleichbar, da dies ja eine Variante von Intel ist mit komplett unterschiedlichen Kernen.

Ich verstehe nicht warum man so eine CPU auf den Markt wirft, ein angepasster 14900K mit der Fertigung bei TSMC und fertig wäre der 15900k dann mit L4 Cache und das ding hätte alles weggebrannt.

Ich sage mal, dass es am Geld liegt: Chiplet sind eigentlich günstiger und ich behaupte, dass das Design in Intel 20A oder 18A, Hauptsache selbst produziert, wesentlich bessere Marge bringen würde als ein 15900K komplett von TSMC gefertigt. Intel hat nicht umsonst nach außen Chiplets erst schlechtgemacht, nach innen aber trotzdem den Weg eingeschlagen. Man weiß um die finanziellen Vorteile und ist daher auch daran interessiert, genau so eine Architektur zu etablieren, da man so mehr Marge macht als zuvor.
Ob das nun mit der TSMC-Fertigung des wichtigsten Bauteils immernoch so ist wissen wir ja nicht, da es bis zum Frühjahr noch hieß man macht es selbst und man langsam auch bisserl an Ruf zu verlieren hat. Aber der Schritt wird trotzdem v.a. rein finanzieller Begründung sein.

 

[BAR86]

Ich sage mal, dass es am Geld liegt: Chiplet sind eigentlich günstiger

das ist pauschal einfach schwierig zu sagen:
mehrere Chiplets zu haben, zu "verkleben" etc sind auch einige Schritte, inkl. Fremdfertigung, höhere Latenzen etc.
Es hängt von verschiedenen Faktoren ab, Chiplets sind nicht pauschal günstiger. Aber es erhöht die Flexibilität, dass man aus einem Baukasten an fertigen Teilen zusammenbauen kann, statt alles gleichzeitig fertig zu bringen, testen usw und dann als einen Chip zu fertigen. Ein kleiner Monolith hätte hier etwa viele Vorteile gegenüber einem Chipletdesign, etwa bei Latenzen und Abwärme.
Je größer ein Chip wird, desto schwieriger die Fertigung (blabla, das ist uns eh bekannt) und dann wirds halt teurer. Außer natürlich in speziellen Märkten wo die Vorteile dennoch überwiegen und es egal ist, wenn die Produktion ein paar Dollar mehr kostet, dafür aber ein paar tausender draufgelegt werden könnten.

Ich kann im Moment auch nicht nachvollziehen wo genau bei Intel nun die Probleme liegen. Ist EMIB/Foveros der falsche Weg? Warum verbrädt man nach wie vor mehr als AMD. Wäre ein reiner, kleiner 8 oder gar 16-Kerner in TSMC N3E nicht schneller/effizienter?

Jedenfalls hat man bei den Core Ultra 2xx nun gesehen, dass der Fertigungsvorteil von TSMC gar nicht so viel bringt wie erhofft im Vergleich zu Intel 7 Monolithen. Und der manchmal erwähnte Bartlett Lake wäre in einer aktuellen Architektur samt 18A Prozess nächstes Jahr ein spannendes Stück Technik... aber nur in unseren Köpfen existent.

 

[foofoobar]

Jedenfalls hat man bei den Core Ultra 2xx nun gesehen, dass der Fertigungsvorteil von TSMC gar nicht so viel bringt wie erhofft im Vergleich zu Intel 7 Monolithen. Und der manchmal erwähnte Bartlett Lake wäre in einer aktuellen Architektur samt 18A Prozess nächstes Jahr ein spannendes Stück Technik... aber nur in unseren Köpfen existent.

Es ist nun wirklich nicht schwer den Fertigungsvorteil von TSMC mit einem schlechten Design zu verkacken.

 

[BAR86]

@foofoobar Es ist nicht klar was schief gelaufen ist:
1. Die Architektur der Kerne- eher nicht.
2. Die vielen "Verbindungen" aufgrund der Chiplets?
3. Foveros/EMIB?
4. Dass der Prozess nicht wie vorgesehen/über seinen optimalen Einsatzzweck hinaus verwendet wird...?

Gegen ersteres spricht Lunar Lake. Für die Dinge dazwischen spricht einiges und auch für das Letztere, denn mit etwas Hand-Tuning bekam CB ihn ja dann endlich effizienter hin als Zen 5.

Also ja, vielleicht am Prozess vorbeidesigned, aber der Fertigungsvorteil scheint dann eben auch keiner zu sein. N3E ist effizienter aber nicht schneller, will man damit also schnell sein verliert er die Effizienz. Es ist vielleicht also der falsche Prozess und N4P wäre besser gewesen.

Ob ich da richtig oder falsch liege wird etwa auch Arrow Lake fürs Notebook zeigen.

Ähnliche ist das Intel selbst ja oft ergangen, etwa vom Wechsel auf 10nm. Der Prozess war Dichter, effizienter, aber nicht gut Taktbar zu Beginn.
18A wird Anfangs dasselbe Problem haben, deshalb ist er zuerst Mal nur für Mobile gut.
Man kann für Intel hoffen, dass sie den Prozess schnell soweit haben, dass er auch auf über 5 GHz zu kriegen ist, sonst schaut's im Desktop düster aus.

 

[K3ks]

Man munkelt @ Gaming sind die Latenzen von AL an einer oder mehreren Stellen zu hoch. -> Chip zu Chip? Kern zu Kern? Da Speichercontroller auf einem seperaten Die? 🤷‍♂️ Anwendungsleistung scheint ja okay zu sein.

 

[BAR86]

@K3ks Ja, das ist ogar klar ersichtlich