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

Juri-Bär · Gestern um 22:30

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 · Heute um 07:27

mae schrieb:
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:

Code:

$ 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.

mae schrieb:
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:

Code:

$ 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 · Heute um 17:56

foofoobar schrieb:
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

Code:

[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 · Heute um 19:29

mae schrieb:
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:

Code:

$ 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 · Heute um 20:33

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

Code:

$ 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


$

Suche

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

Juri-Bär

Captain

foofoobar

Captain

mae

Lt. Commander

foofoobar

Captain

foofoobar

Captain

Ähnliche Themen

Passend zum Thema

Intel Core Ultra Die Preise und das Angebot zum Marktstart in Deutschland

CB-Funk-Podcast #88 Jan und Fabian besprechen den Test zu Intel Core Ultra 200S

Beste Leistung vs. Ausbalanciert Mit Windows' Standard-Profil ist Core Ultra 200 zu langsam