wagga schrieb:
Wie groß ist der Leistungsunterschied von P-Core zu E Core
Ich habe das jetzt einmal auf einem NUC mit Core i3-1315U gemessen, wobei der Prozessor dabei auf WIMRE 3800MHz bei den P-Core und 2600MHz bei den E-Cores limitiert ist (auf der Intel-Seite stehen jeweils 700MHz mehr). Als Benchmark verwendete ich einen
LaTeX-Benchmark. Vor zehn Jahren habe ich bei einem Core i7-6700K gemessen, wieviel SMT bringt, mit folgendem Resultat:
Code:
2 cores 1core 2threads event
868M750k967 1526M150k379 cycles
1949M558k752 1949M705k920 instructions
Nach diesen Resultaten war es nur 1,14 mal schneller, zwei Laeufe auf einem Kern mit SMT zu machen als zwei Laeufe hintereinander auf dem selben Kern (869*2/1526), SMT brachte also fast nichts. Ich habe nicht herausgefunden, was den Durchsatz auf Skylake begrenzt hat, der IPC beider Threads zusammen von 2.55 ist deutlich unter dem Limit von 4 auf Skylake, und andere Begrenzungen habe ich auch nicht gefunden.
Wie man unten sieht, ist das bei Golden Cove inzwischen deutlich besser, wobei es auch eine andere LaTeX-Version mit anderen Zusatzpaketen ist, was sich in unterschiedlichen instructions und auch auf der selben CPU in unterschiedlicher IPC niederschlaegt, die Ergebnisse sind also nur bedingt vergleichbar, aber eine grundsaetzliche Aehnlichkeit duerfte schon da sein (der 6700K ist mir leider verstorben, und so habe ich keine einfache Moeglichkeit, Skylake mit dem neuen LaTeX mit SMT zu messen; ohne SMT sehe ich tendentiell etwas weniger IPC auf Skylake als bei den Messungen damals).
Also jetzt zum Core i3-1315U: Die Messungen mit "Kernen" 0 und 2 sind im Prinzip P-Kerne ohne SMT (ich war zu faul, SMT abzuschalten, sondern habe dafuer die extra-Threads einfach nicht belastet). Messungen mit den "Kernen" 0 1 2 3 sind die 4 threads der zwei P-Kerne. Messungen mit 4 5 6 7 sind die 4 E-Kerne. Die Messungen erfolgten mit z.B.:
Code:
for i in 0 2 ; do (mkdir -p $i; cd $i; cp ../bench.tex ../types.bib .; latex bench >/dev/null; bibtex bench >/dev/null; latex bench >/dev/null; taskset -c $i perf stat -r 100 latex bench >/dev/null 2>timing) & done; wait; cat [02]/timing
Jeder LaTeX-Lauf fuehrte ca. 2667M Befehle aus (1,37 mal soviel wie bei den Skylake-Messungen vor zehn Jahren). Die gemeldete "elapsed time" ist auf dem NUC immer signifikant laenger als die CPU-Zeit (bei diesen Runs lag die CPU-Utilization im Bereich zwischen 0.695 und 0.822); mir ist nicht klar, warum das so ist (duerfte aber mit NFS zu tun haben, als root sehe ich diese niedrige CPU-Utilization bei diesem Benchmark nicht), auf anderen Maschinen sehe ich bei diesem Benchmark CPU-Utilization nahe 1, aber die haben keine Intel P- und E-Cores. Ich zeige also im folgenden die CPU-Zeit, berechnet aus Cycles und MHz.
Code:
W MHz MCycles IPC CPU-Zeit Cores Verwendet
28 3595 1300 2.05 0.362s P 01234567 (P mit SMT und E)
28 2499 1135 2.35 0.454s E 01234567 (P mit SMT und E)
20 3783 1237 2.15 0.327s P 0123 (P mit SMT)
12 3683 902 2.95 0.245s P 02 (P ohne SMT)
8 2562 1132 2.36 0.442s E 4567 (E-Cores)
Die ersten beiden sind der gleiche Run, in der ersten Zeile die Werte fuer die P-Cores und in der zweiten die fuer die E-Cores. Interessanterweise steigt der IPC, wenn die E-Cores nicht gleichzeitig arbeiten. Da der Benchmark eigentlich wenig cache misses hat, ist mir nicht klar, warum. Beim Run ohne SMT hat Core 0 nur 2.87 IPC (Core 2 wird gezeigt).
Bei diesem Benchmark ist auf dieser Hardware also ein P-Core mit SMT noch etwas schneller als 2 E-Cores, kostet aber 2.5 mal soviel Energie (waere interessant, wie's ausschaut, wenn alles auf 8W beschraenkt waere). Der IPC eines Threads eines P-Cores ist bei diesem Benchmark geringer als der eines E-Cores, bei gleicher Taktfrequenz waere der E-Core also schneller. Der P-Core ohne SMT ist aber bei der IPC deutlich ueberlegen und bei der Taktfrequenz auch, dafuer braucht er mehr Strom. Wenn man zwei solche LaTeX-Laeufe hintereinander auf einem P-Core ohne SMT durchfuehren laesst, und im Vergleich dazu dasselbe gleichzeitig auf den beiden threads eines Cores, ist man mit SMT 1.5 mal schneller; das ist ein grosser Fortschritt im Vergleich zu Skylake und SMT hat fuer Anwendungen wie diesen Benchmark anders als auf Skylake durchaus einen Sinn. Inwieweit P-Kerne mit SMT auf einer Serverplatform, wo jeder Kern nur 1-3W verbrauchen darf, gegen E-Kerne bestehen koennen, ist aber immer noch die Frage.
P.S.: Das gleiche auf einem Ryzen 8700G, wobei dort die LaTeX-Installation eine andere ist, und es insgesamt mehr Pakete gibt, sodass die Anzahl der ausgefuehrten Befehle 3563M ist (also um den Faktor 1.34 mehr als bei den Resultaten oben). Diesmal habe ich SMT tatsaechlich abgeschaltet, um Messungen ohne SMT zu bekommen. Die Ergebnisse sind:
Code:
W MHz MCycles IPC CPU-Zeit Cores Verwendet
86 4702 2084 1.71 0.443s Zen4 0-15 (SMT)
72 4792 1425 2.50 0.297s Zen4 0-7 (SMT abgeschalten)
Hier sind zwei LaTeX-Laeufe auf einem Kern mit SMT 1.34 mal schneller als wenn man sie hintereinander auf dem selben Kern ohne SMT ausfuehrt, allerdings bei einer um den Faktor 1.19 hoeheren Leistungsaufnahme.
Und hier noch eine Anwendung, die tatsaechlich parallelisierbar ist (waehrend ich beim LaTeX-Benchmark nur mehrere single-threaded runs parallel gemacht habe, was im Normalfall nicht sinnvoll ist): 2000x2000-Matrixmultiplikation mit double-precision FP-Zahlen, mit Hilfe von libopenblas, das schon intern parallelisiert. Aufrufe fuer die Messungen auf dem Ryzen 8700G:
Code:
OMP_NUM_THREADS=16 perf stat -r 100 openblas 2000
OMP_NUM_THREADS=8 perf stat -r 100 openblas 2000
OMP_NUM_THREADS=8 taskset -c 0-3,8-11 perf stat -r 100 openblas 2000
for i in 0-7 8-15; do OMP_NUM_THREADS=8 taskset -c $i perf stat -r 100 openblas 2000 & done; wait
Hier die Ergebnisse:
Code:
W MHz MCycles Minsts IPC elapsed Cores Verwendet
73 4774 7185 4894 0.68 0.0987s Zen4 0-15 (SMT)
63 4805 2702 3322 1.23 0.0755s Zen4 0-7 (SMT abgeschaltet)
51 4818 3797 3062 0.81 0.1014s Zen4 0-3,8-11 (SMT, 4 Kerne, 8 Threads)
81 4693 3534 3204 0.91 0.1078s Zen4 0-7 8-15 (SMT, zwei Multiplikationen parallel)
81 4746 4111 3159 0.77 0.1139s Zen4 0-3,8-11 4-7,12-15 (SMT, zwei Multiplikationen parallel)
Hier wird die Anwendung durch Verwendung von doppelt sovielen Threads auf SMT also langsamer als ohne SMT, und zwar v.a. weil mehr Befehle ausgefuehrt werden (wohl Synchronisationsoverhead). Um dieses Problem zu eliminieren, habe ich auch mit 8 threads auf 4 Kernen+SMT gemessen. Das Ergebnis war interessanterweise kaum langsamer als bei 8 Kernen/16 threads. Im Vergleich zu 8 threads auf 8 Kernen ist die SMT-Variante um den Faktor 1.34 langsamer, aber braucht auch nur halb soviele Kerne.
Wenn man wie bei LaTeX die Ausfuehrung zwei mal hintereinander ohne SMT mit der Ausfuehrung von zwei solchen Matrixmultiplikationen parallel mit SMT auf jeweils 8 threads vergleicht, hat die SMT-Variante einen Durchsatz, der um den Faktor 1.4 hoeher ist. Ich habe das verglichen, indem ich jede Matrixmultiplication auf allen Cores laufen liess (0-7 8-15), oder indem ich jede auf 8 threads auf 4 cores laufen liess (0-3,8-11 4-7,12-15). Die Performance letzterer Variante ist etwas niedriger, dabei haette ich erwartet, dass sie besser abschneidet, weil weniger zwischen den Caches verschiedener Cores hin- und herbewegt werden muss; offenbar ist etwas anderes wichtiger fuer die Laufzeit.
