- iPhone topik
- Magisk
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Fotók, videók mobillal
- MIUI / HyperOS topik
- Samsung Galaxy Z Flip7 - kis fogyás is sokat jelent
- Samsung Galaxy S25 - végre van kicsi!
- Vivo X200 Pro - a kétszázát!
- Xiaomi 15 - kicsi telefon nagy energiával
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
Új hozzászólás Aktív témák
-
kfr@
csendes tag
Nem. Azért veri meg az 5950x a 3990x-et, mert a 3950x is elveri a 3990x-et, az 5950x pedig 15-20%-kal gyorsabb, mint a 3950x.
Amúgy a Zen3 prociknál jelentősen változtattak a teljes memória architektúrán, úgyhogy érdekes lenne egy (elképzelt) 5990x-et is látni ezen a grafikonon, hogy ott is (ennyivel) lassabb lenne-e a 64 magos teljesítmény a 16 magoshoz képest.
A grafikonod szerint 7zip betömörítésben a 16 magos Zen2-es 3950x gyorsabb, mint a szintén Zen2-es, de 64 magos 3990x, és saccra kb. 15-20%-kal lassabb, mint a Zen3-as 5950x.
Vagyis az ALU sebességének itt nem sok szerep jut, hacsak nem hisszük el, hogy a 3990x ALU-ja alig 50-60%-át tudja a 3950x-esének. Ami (tekintve, hogy ugyanaz a Zen2-es ALU, kicsit alacsonyabb órajelen) irreális, kivéve, ha a 3990x throttlingol végig.
Amit a grafikonon látunk, hogy a 7zip nem jól skálázódik Zen2 architektúrán. Amit valószínűleg az okoz, hogy a 8db CCD az 1db I/OD-n keresztül beszélget egymással, és a 7zip-nek valamiért erre szüksége lenne. Így még az is felmerül, hogy egy 8magos (1CCD-s) 3xxx Ryzen még gyorsabb lenne betömörítésben...
A Zen3-ról nem tudtuk meg a 7zip skálázódását, hiszen nincs a tesztben másik Zen3 cpu.
Lehet valós igény, hogy valaki egész életében 7zip betömörítést akar futtatni, de meglehetősen szűk rétegnek gondolom ezt a felhasználást. Aki meg mást szeretne csinálni, az azzal teszteli, vagy olyan teszteket néz meg. -
hapakj
őstag
De hát igazából te is csak mazsolázgatsz
"a masszívan párhuzamosítható feladatok között van olyan, ami gyorsul, de ez a gyakorlatban messze elmarad az elvárt magszám alapján elvárt skálázódástól"
- amióta világ a világ minden architektúrának vannak előnyei és hátrányai. Egy hw cégnek az a feladata, hogy abba az irányba vigye tovább a cuccait, amire a legnagyobb igény van.Valószínűsítem, hogy 192 szálon buildelni, vagy sok gépet virtualizálni sokkal elterjedtebb usecase, mint 192 szálon zippelni
-
sb
veterán
Először azt hittem magardól írsz... mert hát, igen, az is egyetlen példa volt.
Ráadásul tudjuk - te is leírtad - hogy eléggé nem átlagfeladat ha az erőforrás bottleneck-eket nézem.Be lehet dobni általános teszteket is, nem lesz igaz amit írsz. Van gyorsulás.
Azon meg továbbra sem kéne lovagolni, hogy milyen feladat párhuzamosítható önmagában ennyire jól. Kevés. Itt párhuzamos feladatfuttatások játszanak inkább továbbra is.Továbbra sem raknak tele szobákat 16 magosokkal, ellenben több ezer magos szerverkonfigok futnak sok helyen. Akkor wtf? Ha elvi szinte kanyarodunk akkor is mazsolázol:
Vannak fizikai korlátok, ahogy írod. És ezeknek több (akár fizikai-logikai) vetülete.
1. Méret/hely mást is magával hoz, hűthetőség, stb...
2. A logikai felépítés is jobb lehet: ha párhuzamos kiszolgálásra kellenek - mint a szerverek nagy része - akkor az a felépítés a lassabb amit te favorizálsz: kevesebb mag, több feladat/mag: több kontextusváltás. Optimálisabb a többmagos felépítés.
3. Visszakanyarodhatunk a feladattípusra is. Egyébként ilyen szempontból a "mazsolázásnak" is van relevanciája. Tök más feladatra vesz gépet egy adatközpont mint egy tudományos-szimulációs célú szerverpark. Lásd még mindig a gpu-s példát, mint kisarkítást. Van olyan feladatra amire az csak levélnehezéknek jó, másban meg leveri a cpu-s konfigokat.
4. Amiben elvi szinten van igazad - bár nem mondtad ki - hogy a perf/W-ban nincsenek csodák. Adott fogyasztásból X vagy 2X mag nem fog 2x szorzót hozni. Persze nemlineáris a kapcsolat, nem csak freki, feszültség, stb. is számít... de itt valóban nincsenek egy adott magszám felett nagy csodák. De nem is ez a lényeg, ez csak egy dimenzió. A fentiek inkább számítanak. Egyrészt van a nyers teljesítményen kívül egy rakás más szempont, sávszélesség, adatkapcsolatok, az sw/algoritmus oldal, amit írtál, feladatok száma... ezért a nyers perf, perf/W-on felül lesz egy csomó minden ami javíthatja vagy ronthatja a hatékonyságot ezen felül.Továbbra is úgy néz ki, te emeltél ki egy dolgot: kevés (nehezen párhuzamosítható) feladat + más bottleneck-ek vs sokmagos felépítésű rendszer kizárólag nyers számítási ereje.
-
Pikari
veterán
Mazsolázgatásnak hívják azt, amikor az elképzeléseidnek kedvező eredményeket megmutatod, a többiről hallgatsz. Ez egy érveléis hiba. Abu viszont ennek szellemében mutatott egy grafikont, amire válaszul én is egy grafikont mutattam.
A valóság meg a kettő között van.
Summa summarum, a masszívan párhuzamosítható feladatok között van olyan, ami gyorsul, de ez a gyakorlatban messze elmarad az elvárt magszám alapján elvárt skálázódástól, erről szólt a második kommentem, amire abu is reagált.
Ettől függetlenül persze lehet, és van is létjogosultsága ezeknek a processzoroknak. Még ha nem is azért, mert hogy esetleg jobbak lennének teljesítményben és fogyasztásban ahhoz képest, mintha 5 gépet tennél le, hanem azért, mert ha mondjuk a számítógépes rendszered csak egy szobát foglal el ahelyett, hogy egy egész emeletet kéne telerakni vele, akkor sok esetben meg fogja érni. Kissebb méretű vállalkozásoknak is jó lehet, ha emiatt rendkívüli módon egyszerűsíthető a szoftveres oldal, például ha mondjuk az összes ügyfeled virtuális gépeit egy gépen futtathatod. Csak épp az a teljesítménybeli skálózádás, amit sokan elképzelnek ezektől, nem létezik.
-
sb
veterán
Hoztál egy példát ami ebben a formában mástól függ. Ettől még miért ne lehetne jól skálázódó más feladat amiben nem ez a bottleneck? Kisarkítva kicsit olyan mintha most bedobnál valamit ami jól fut gpu-n és kihoznád, hogy semmit nem ér az Epyc mert nincs benne gpu.
Egyébként pedig ezek szerver cpu-k, kiszolgálók. A legegyszerűbb példa ott indul, hogy ne egy feladatot keress ami többszálúsítható végtelen arányban úgy, hogy közben vannak közös kontextusai. Sokkal egyszerűbb példa egy feladat ami sok példányban fut, tök függetlenül egymástól.
-
Abu85
HÁZIGAZDA
De hozzál már rá bizonyítékot, mert csak ismételgeted magad, de nem bizonyítod. Igen értettük, te így gondolod, de nem azt mondod, hogy szerinted, hanem azt, hogy ez így van. Ha viszont így van, akkor bizonyítsd, mert gondolom ezt tesztben láttad és nem csak álmodtad. Ha utóbbi, és nem láttál Turin Dense tesztet, ami bizonyítja az állításaid, akkor meg felesleges az egész eszmecsere, mert csak a véleményed írod le, nem a tényeket.
-
Pikari
veterán
Nem kifejezetten 12 csatornás 192 magos epycekről olvastam ma teszteket, hanem sokmagos processzorokról kerestem teszteket, és nagyon kiábrándító volt mindegyiknek az eredménye. Például arról, amiről a grafikont is beszúrtam.
Ez a skálázódási probléma egy általános jelenség, önmagában a memóriacsatornák számának növelése nem oldja meg, ez egy szükséges de nem elégséges előfeltétel - mint ahogy a 3990x-nél sem oldotta meg az, hogy megduplázták a memóriacsatornák számát.
-
Abu85
HÁZIGAZDA
Nem a logikádra vagyok kíváncsi. Hozz bizonyítékot arra, hogy nem skálázódik jól a 192-magos EPYC a 12 memcsatornával. Azt írtad, hogy "...bármilyen review ilyen skálázódást mutat az elmúlt 5 évből. Épp ma olvastam végig két ilyet." Gondolom akkor tudsz hozni bizonyítékot erre egy Turin Dense platformmal.
-
Pikari
veterán
Bebizonyította a grafikonom, hiszen az 5950x egy 16 magos processzor 2 memóriacsatornával, a 3990x pedig egy 64 magos processzor 4 memóriacsatornával, mégis az 5950x a kétszer gyorsabb a kettő közül 7z tömörítés alatt. Ebből logikailag következik az, hogy a plusz memóriacsatornák száma ebben az algoritmusban nem segítet érdemben.
Ennél több memóriacsatornára maximum a jóval memóriasávszélességintenzívebb feladatokban lehet szükség.
-
Pikari
veterán
-
Pikari
veterán
A masszívan többszálúsított feladatok nagy részében a 64 magos epyc a 16 magoshoz képest tipikusan 2x-es sebességtöbbletet tud felmutatni azonos órajelen. Ennek azoka a programozásban, a kernelekben, és magában a hardverekben is keresendő, és nincs olyan megnyugtató jel arra, hogy ebben érdemi változás történhessen.
És a félreértések elkerülése végett, ez a számérték a VALÓDI feladatok alatti skálázódást mutatja, és még véletlenül sem azt, hogy valaki elindít 200 threadon egy üres while ciklust, ami számokat ad össze.
Ja nem, tök drága lenne üzemeltetni egy tucat 16-magos gépet, egy 192-magos proci helyett.Új hozzászólás Aktív témák
Hirdetés
- Trance club
- Synology NAS
- Linux kezdőknek
- Apple MacBook
- Eredeti játékok OFF topik
- Nintendo Switch 2
- Kerékpárosok, bringások ide!
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- AKCIÓ! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- BESZÁMÍTÁS! Lenovo Legion 5 17ACH6H Gamer notebook - R7 5800H 16GB DDR4 512GB SSD RTX 3060 6GB WIN11
- AKCIÓ! ASUS H81M-PLUS H81 chipset alaplap garanciával hibátlan működéssel
- Eladó megkímélt állapotban lévő Xiaomi 12T Pro 8/256GB / 12 hó jótállás
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest