A leginkább technikai az, hogy a P-cores (P=performance) az 2-szer akkora területet foglal el a chipben, mint az E-cores (E=Efficiency).
Mit mond Linux 6.1.0-37 (Debian-12) kernelem ezekről? Az első két core (0,1) tud HT-t (Hyperthreading) de ezt a funkciót kikapcsoltam.
CPU típusa: 13th Gen Intel(R) Core(TM) i7-1355U
Összesen 10 mag, HT bekapcsolásával 12-nek látszik.
| core | Max Hz | Base Hz | Min Hz | L1 d | L1 i | L2 | L3 |
|---|---|---|---|---|---|---|---|
| 0 | 5.0 | 1.7 | 0.4 | 48kiB | 32kiB | 1280kiB | 12MiB |
| 1 | 5.0 | 1.7 | 0.4 | 48kiB | 32kiB | 1280kiB | 12MiB |
| 2-5 | 3.7 | 1.2 | 0.4 | 32kiB | 64kiB | 2048kiB | 12MiB |
| 6-9 | 3.7 | 1.2 | 0.4 | 32KiB | 64kiB | 2048kiB | 12MiB |
Memória-topológia:
memóra - 2 csatorna
\- L3 cache (12MiB) (megosztott)
\- L2 cache (1280kiB)
| \- L1 i cache (32kiB) d cache (48kiB) - core0
\- L2 cache (1280kiB)
| \- L1 i cache (32kiB) d cache (48kiB) - core1
\- L2 cache (2048kiB)
| \- L1 i cache (64kiB) d cache (32kiB) - core2
| \- L1 i cache (64kiB) d cache (32kiB) - core3
| \- L1 i cache (64kiB) d cache (32kiB) - core4
| \- L1 i cache (64kiB) d cache (32kiB) - core5
\- L2 cache (2048kiB)
\- L1 i cache (64kiB) d cache (32kiB) - core6
\- L1 i cache (64kiB) d cache (32kiB) - core7
\- L1 i cache (64kiB) d cache (32kiB) - core8
\- L1 i cache (64kiB) d cache (32kiB) - core9
Látható, hogy az L2 cache megosztott az E-cores esetében, de dedikált a P-cores esetében.
Gyártási topológia: Egy tokozásban egy chip. A chipben 4 clusterbe vannak rendezve a magok, ez megfelel a fenti táblázat 4 sorának. Ezen kívül a memóriavezérlő, jónéhány periféria és egy grafikus processzor is van a chipben.
Ezek (frekvencia és cache size) még önmagában nem indokolná a jelentős méret-, és teljesítméménykülönbséget. A leírások mindenféle belső utasitás-feldolgozókról, párhuzamosságokról szolnak. Meg arról, hogy az E-core valójában egy 6th Gen Intel Core új gyártástechnilógiával.
De mit tud az egész valójában? Van nekem egy flops számoló programom, (fejlesztés alatt) ami elég jól boldogul a több egyforma maggal, de nem tudja jól használni a különböző teljesítményű magokat. Sebaj, az egyedi magok teljesítményét össze tudom vele hasonlítani. Maradjatok velem, 1-2 nap alatt lemérem ezeket.
- egeresz blogja
- A hozzászóláshoz be kell jelentkezni
- 670 megtekintés
Hozzászólások
subscribe
... The vision and the mission lost,
For those with corporate souls ...
Slackware Linux current | 5.10.38-janos
- A hozzászóláshoz be kell jelentkezni
for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ; do echo performance > $i ; done cd /sys/fs/cgroup echo "+cpuset" > cgroup.subtree_control mkdir perftest echo 174701 > perftest/cgroup.procs # ez a teszt shell pidje echo 1 > perftest/cpuset.cpus # aztán echo 0-1, aztán echo 2-3 stb
És ezek után futtatom a programom.
| feltétel | FP32 Gflops | FP64 Gflops |
|---|---|---|
| 1 P-core | 23.6 | 9.3 |
| 2 P-core | 43.5 | 17.8 |
| 1 E-core | 9.7 | 4.4 |
| 2 E-core | 19.4 | 8.6 |
| 4 E-core | 35.6 | 16.0 |
| 8 E-core | 57.2 | 20.5 |
Megjegyzem, hogy a mérőprogramom egy szimpla többszálú lebegőpontos szorzás (mátrixszozrás), ami nagyon szépen tudja használni a E-core közös L2 cache-ét. (Merthogy közös az adat). Várhatóan lassabb lenne, ha más adaton számolna a másik szál. Mindenesetre látható, hogy az E-core tényleg sokkal lassabb, azonban nagy száma miatt egy jól párhuzamosítható algoritmust érdemesebb azokon futtatni.
Most gondolkodhatok, hogyan lehetne valami automatizmussal az algoritmust jól teríteni ezekre a különböző magokra.
- A hozzászóláshoz be kell jelentkezni
Ez ugye, egy notebook cpu. Hogy lássunk valami nagyon mást is, ugyan ez a program, AMD Ryzen 7 9800x3d -on:
FP32: 454.8 Gflops
FP64: 199.7 Gflops
- A hozzászóláshoz be kell jelentkezni
egy core-on merve mennyire jon ki?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Most nincs Ryzen 7 9800x3d, van helyette Ryzen 5 9600X (ez ugye, egy jóval gyengébb, 6 core+HT = 12vcore)
| vCores | FP32 Gflops | FP64 Gflops |
|---|---|---|
| 12 | 271 | 114 |
| 8 | 243 | 110 |
| 4 | 128 | 63 |
| 2 | 104 | 52 |
| 1 | 52 | 27 |
Azon csodálkoztam is, hogy a HT ennyit számít (2vCores = 1 Core). Ez a jelenséget Ryzen 7 9800x3d esetén is tapasztaltam (mármint, hogy a HT az jó).
A méres tulajdonsága, hogy erősen memória-sávszélesség intenzív. A memóriabusz hamar szaturál, és utána kevéssé nő a teljesítmény a magok számával.
- A hozzászóláshoz be kell jelentkezni
Akkor ha jól értem, erős a gyanú, hogy a X3D cache jócskán rásegített.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Igen. Ez mátrixszorzás. Két óriási tömböt kell beolvasni, és bizonyos szabályok szerint szorozni-összeadni. Nagyon macerás cache-optimális algoritmust készíteni, emiat, igen, a nagy méretű cache ebben a feladatban létfontosságú. Egy másik tesztet is végeztem ezekkel a procikkal: python 3.12 build&install. Az szigorúan specint jelleű feladat, és különböző szálak különböző adaton dolgoznak.. Hiába nvme diszkek meg nagy belső memória, az a Ryzen7 7800x3d | Ryzen7 9800x3d brutálisan gyors volt. Sajnos nem mértem időt, de azt hittem, elesett. Pedig lefutott. Ehhez képest a Ryzen 5 9600X az 1:07 min:sec, ami nagyon szép érték de nem hihetetlen.
- A hozzászóláshoz be kell jelentkezni
Nem lennének ezek rosszak, csak kár, hogy a gamerek az egekig felverték az árát. Az, hogy a 8 magos 9800x3d-k már nem ritkán a 16 magos 9950x-ek feletti árakon mennek, enyhén abszurd.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Ugy emlekszem, ha a jobb matrixot elso lepesben transzponalod, sokkal gyorsabb lesz, mert a cache-bol sorfolytonosan olvasod a szamokat. Szoktak ilyesmivel trukkozni matrixos libek. Volt errol youtube-on egy video, valaki pont egy matrixszorzast optimalizalt - amennyire tudott. Az utolso valtozatban mondjuk pont a transzponalos lepest kihagyta, mert mar nem a cache-en akadt meg az algoritmusa.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Transpose: igen, úgy is van. Meg opencl esetében van vectordot utasás, ha lehetőség van, használva. Meg igazítás mindenféle byte-méretre. Sikerült felülmúlnom a 40 éve reszelgetet blas::dot() sebességét, akkor hagytam abba az optimalizációt. Az volt a progival az elsődleges célom, hogy CPU-GPU ár/teljesítmény összehasonlításhoz kapjak méréseket.
Azt is mondjuk ki, hogy a numpy.matmul nagyságrendekkel gyorsabb. (Gondolom gyorsabb alguritmust használ eleve.) Ha valóban mátrixot kellene szoroznom, akkor np/jax; de nem mátrixot szorzok, hanem CPU-t mérek.
- A hozzászóláshoz be kell jelentkezni
Ez a notebook cpu tartalmaz intel GPU-t. Ez meghajtható számolási célra OpenCL segítséggel. Sajnálatosan nincs benne fp64 támogatás (csak fp16, fp32 meg int)
| hogyan | FP32 Gflops | FP64 Gflops |
|---|---|---|
| GPU | 101.5 | |
| CPU HT off | 67.5 | 24.4 |
| CPU HT on | 81.4 | 29 |
- Hehe, ebben a chipben erősebb GPU van (FP32 szempontjából) mint az összes core egyszerre.
- A P-core gyorsabb, mint az E-core, emiatt a mérési program egyenletes terítése nem optimális. (A P-core hamarabb végez a feladattal, és utána vár)
- Viszont a P-core a korábbi mérések alapján cca 2-szer gyorsabb, mint az E-core, így a P-core feldarabolása kétfelé (HT) nagyjából egyenlő erejű vCore-kat eredményez, így a programom teritése cca optimális. Jobb is lett az eredmény.
- Az buli lenne, ha egyszerre tudnám meghajtani a GPU és a CPU részt, összeadva a teljesítményüket. Várhatóan a notebook gyengécske hűtése lenne a limitáló tényező; vagy egyenesen a tápegység (ez a CPU 55W-ot tud enni, a tápegység egy szokásos USB-c 65W)
- A hozzászóláshoz be kell jelentkezni
Subscribe
- A hozzászóláshoz be kell jelentkezni
énisénis
- A hozzászóláshoz be kell jelentkezni
És az mennyit számít(hat) hogy az E core-ok instruction cache-e 2x akkora?
- A hozzászóláshoz be kell jelentkezni
Ezen gondolkodtam erősen. Várhatóan azért esett az intel választása erre a drága megoldásra, hogy ellensúlyozza a megosztott L2 cache tulságosan is lassító hatását. Talán. Mindenesetre többször ellenőriztem, hogy jól látom-e.
- A hozzászóláshoz be kell jelentkezni
Ez engem érdekel! :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Másik mérés: Python interpreter fordítása.
| Aktív magok | WallClock | CpuTime | rate |
|---|---|---|---|
| 2P+HT+8E=12vCPU | 117.512 | 659.801 | 5.6 |
| 2P+HT | 195.570 | 578.035 | 2.9 |
| 8E | 156.402 | 600.322 | 3.8 |
| 2P+noht+8E | 132.248 | 719.960 | 5.4 |
| 2P+noht | 209.470 | 342.747 | 1.6 |
| 4E (két L2) | 205.186 | 535.075 | 2.6 |
| 4E (közös L2) | 211.960 | 560.198 | 2.6 |
Összefoglaló:
- Megéri a HT-t bekapcsolni (+20%)
- itt is 4 darab E-core hasonló eredményt adott, mint 2 darab P-core
- gyorsan felszaladt a hőmérséklet 80 C⁰ fölé, felzúgott a venti, levette a CPU frekvenciát
Megjegyzések:
- Python 3.12.11 fordítása make -j $NUM
- gcc 12.2.0
- Minden python module-hoz megvan minden, tehat full make
- A feladat érdekessége, hogy van benne egy hosszas 1 szálú tesztelés, nem tiszta párhuzamos
- Clean reboot, no browser, no mailer.
- A legelső mért futtatás elött egy "cache-warmup" futtatás.
- Minden futtatás után megvárjuk, amíg a CPU lehül 50 fokra (leáll a FAN)
- Minden futtatás elöt make clean;
- A notebook töltőn volt végig
- performance intel_pstate mód
- CPU mag limitációk cgroup+cpuset módon
- HT on/HT off beállítás BIOS-ból
- 16Gbyte DDR4-3200 1 darab So-dimm
- Western Digital PC SN740 NVMe SSD, ext4
- ez egy notebook
- A hozzászóláshoz be kell jelentkezni
Összefoglaló
Nem látom értelmét notebook környezetben ennek a P core + E core hybrid CPU koncepciónak. Mielött még érdekes dolgok történtek volna, az egész szórakozást lelimitálta notebook-ban szokásos hűtés gyengesége.
Ha munkaállomás/szerver környezetben képzelem el az egészet, amikor is a hűtés tisztességes és nem gátol, akkor sem látom be, hogy mi értelme volna kétszer annyi darab, de fele olyan drága és fele olyan gyors maggal bővíteni a rendszert. (Ugyanis a leírások szerint 2P+8E cca ugyanannyiba kerül legyártani, mint 6P magot, és nagyjából ugyanannyira is gyors).
Esetleg egy nagyon belépő szintű egygépes virtualizált környezetben, ahol is LAMP szogáltatáshoz a P magokat megkapja a DB, az E magokat megkapja az apache, akkor talán van anyagi előnye.
Amennyiben feltételezzük, hogy a programok vacakul vannak megírva, és az oprendszer ütemezője vacak, akkor ez a hybrid felállás javíthat az interakív reagáláson (latency). Lehet, hogy javít, nem biztos, nem mértem, ötletem sincs, hogyan lehetne objektíven mérni..
- A hozzászóláshoz be kell jelentkezni