- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- sziku69: Szólánc.
- Flashback: Építsünk PC-t akciós alkatrészekből, lassan. upd: 05.28
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bambano: Bambanő háza tája
- Parci: Milyen mosógépet vegyek?
- Luck Dragon: Asszociációs játék. :)
- vrob: Az IBM PC és a játékok a 80-as években
- Gurulunk, WAZE?!
Új hozzászólás Aktív témák
-
#7514
Petykemano
veterán
Ueda
#7512
Petykemano
veterán
Érdemes megnézni ezt a 20perces tesztet, ami nagyvonalakban a N6-on készült 6800U és az N4-en készült M2 összehasonlítására fókuszál.
Megalázó vereség helyett egy erős verseny látható. Az M2 előnye a fogyasztás és akkuidő vonatkozásában nagyvonalakban magyarázza a gyártástechnológiai előny.
[link] -
#7513
Petykemano
veterán
Ueda
#7512
Petykemano
veterán
Ezek, hogy az x86 haldoklik és hogy van élet az x86 halálát követően - elég sarkos kijelentések.
Az x86 részleges monopóliumának lehet, hogy vége, de szerintem az, hogy kinyíltak lehetőségek még nem jelenti az x86 halálát.
Az Apple az egyetlen cég, amely az x86 ISAval dolgozó AMD és Intel kínálatával versenyképes (bizonyos szempontból jobb) processzort tudott tervezni ARM alapon. A gyári arm processzorok IPC tekintetében versenyképesek és ezért a szerverek terén láthatólag tudnak érvényesülni, de a desktop/notebook piacon még hiányzik a teljesítmény. (Amit.az apple IPC-vel, az x86tal dolgozó cégek pedig frekvenciávak hoznak)Természetesen a lehetőségek jók. Az Arm alapon tervező cégek nyilván megpróbálnak majd benyomulni azokra a piacokra, ahol jelenkeg X86 van. Desktop, szerver, konzol. De számos kézikonzol valósul meg manapság x86 alapon.
Csábító, hogy arm alapon saját magadnak is tervezhetsz, de olyan területen, ahol korábban x86 volt, komolyan ezzel eddig csak az Apple és az Amazon élt.
Ezzel együtt azt.el kell ismerni, hogy fordított irány.ritkább, az x86 nem nyomul azokra a területekre, ahol az arm dominál. Ennélfogva csak veszíthet.
Viszont amíg nem válik.általánossá.az Apple által arm alapon produkált előny, ami egyértelművé tenné az ARM ISA felsőbbrendűségét, addig én inkább egy hosszabban elhúzódó haláltusát.várnék,.semmint gyors fűbeharapást.
Persze tévedhetek.
-
HSM
félisten
Azonos órajelen lenne csak ezt értelme nézni. Illetve azonos csip-revíziókkal. Illetve az sem mindegy, hogy mennyi az eközben elvégzett munka. A kisebb L2-es modell azért is lehet elméletben hűvösebb, látszólag "takarékosabb", mert többet kell várnia adatra a memóriából, hiszen kevesebb esetben tud segíteni az L2.
-
S_x96x_S
addikt
> "...1 Golden Cove helyigénye a becslések szerint
> körülbelül 2 Milan(teljes Zen3) magnak felel meg.- A "Golden Cove" eléggé új architektúra;
És ebben is benne van "Jim Keller"-nek a keze nyoma. ( mint a ZEN -nél )- Az AVX-512 és az új AMX kiterjesztés elég sok helyet elfoglal;
és ezek mind hiányoznak a ZEN3-ból.
(talán a kettő együtt - akár 1/3 is lehet helyfoglalásban a teljes magnak)
És csak duplázzuk meg a vektor pipe-linekokat és .. és még több tranzisztort kell beálldozni. ...AVX512/AMX: Az AMD szerencséje, hogy a Desktop- AlderLake-en a Big-Little miatt ezt nagyrészt nem lehet elérni, de szerver szinten elég ütős tud lenni, hogyha a program ki tudja használni.
Az én értelmezésemben az AVX-512 közelit a GPU-k sűrűségéhez;
és nem könnyű hatékony és gyors magokat tervezni erre.
Mert látott már valaki hatékony - 4.5 Ghz-en működő GPU-t ?
- Az nVidia A100 -nak pl. a Boost Clock-ja ~1.41GHz !
- Az RTX 3090 -nek meg 1.70 Ghz ..
A korai Inteles AVX-512 implementációknál - annyira átmelegedett a chip; hogy az AVX-512 -es utasításoknál vissza kellett szabályozni magát .. csak, az volt a probléma, hogy a teljes rendszert lefolytotta."So how does this affect you, if you mix a little AVX-512 with your real workload? We use the Xeon Silver 4116 CPUs, with a base frequency 2.1GHz, in a dual socket configuration. From a figure I found on wikichip it seems that running AVX-512 even just on one core on this CPU will reduce the base frequency to 1.8GHz. Running AVX-512 on all cores will reduce it to just 1.4GHz."
https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/------------
Szóval az AMD-nek egy jól implementált
AVX-512 -öt kell kihoznia a ZEN4-ből - elsőre!A TSNC N5 - azért segíthet a megnövekedett tranzisztorigény kielégitésében.
-
HSM
félisten
Volt egy jó írás még a Renoir-ról, van benne magméret összehasonlítás a teljes L3-as verzióval: [link]
Illetve szerintem érdekes, hogy egy ilyen Renoir 15W-os verzióban gyorsabb Cinebench-ben (2935 pont, forrás: [link] ), mint az új 12900K takarékos magjai (2572 pont, [link] forrás: [link] ).
Illetve az is rendkívül érdekes lenne, illetve szerintem akár alternatív opció lehet AMD oldalon, hogy különbözőképpen paraméterezni firmware-ből a magjaikat. Pl. egy "szoftveres" takarékos mód, ahol néhány magot megjelölnek "takarékos" magnak, és az OS ide rakhatja a kis igényű dolgokat, és ezek a magok ilyenkor nem turbóznának, hanem egy hatékonyságra optimalizált órajelen működnének, mint a mobil csipek esetén is.
Egyébként a jelenlegi magjaikon is lehet ilyesmit "buta" módon, én pl. előfordult, hogy kikapcsoltam a turbót a Ryzen 3600-asomon, mert kb. elfelezte a fogyasztást és bőven elég nagyon sok mindenre 3,6Ghz-en is, lásd mérésem [link] .
Ha a hybrid magdizájn rákényszeríti a szoftvereket, hogy külön kezeljék az erős/hatékony magokat, így külön magdizájn (és ezzel járó hátrányok) nélkül is tudnának ebből profitálni.Az meg már csak hab lenne a tortán, ha pl. lenne egy magasabb és alacsonyabb cache méretű verziója a csipleteknek, amiket lehetne kombinálni. Pl. elvileg lesz egy speciális Zen4 verzió [link] , elég komoly számok a dupla sűrűség és energiahatékonyság, több, mint 1.25X-ös sebesség mellett, bár nyilván itt azért érdemes megvárni azért a tényleges eredményeket.
-
S_x96x_S
addikt
> Lehet nem ártana, ha maga a proci képes lenne programozási nyelvet futtatni.
de Melyik programozási nyelvet? És mi lesz a többivel?
amúgy az már nem X86 lenne
Jelenleg a legtöbb programozási nyelvet - le lehet fordítani gépi kódra ..
amit a hardver tovább fordít mikrokódra> Hiszen az assembly használata úgyis hanyagolva van,
> csupán a fordításra korlátozódik.Miért lenne hanyagolva?
szinte mindennek az az alapja ..A C / C++ is ugyanolyan forráskód - mint az assembler ..
nagyrészt fordításra van használva ... csak magasabb absztrakciós szint ... -
HSM
félisten
"tehát mindenképpen plusz (emberi) munkaráfordítás kell."
Nem vagyok különösebben jártas a fordítók lelkivilágában, de nem úgy van, hogy ha lehetőséget biztosítasz bizonyos utasítások használatára, akkor azokat akár automatikusan is képes bizonyos szituációkban felhasználni? Nyilván, az ideális eredményhez kell emberi ráfordítás is (optimalizáció), de tudtommal nem minden esetben elengedhetetlen.#4569 S_x96x_S : Valami kavarás dereng régebbről, AVX1-2, FMA3-4, ez sem ment egyszerűen...
[link] -
#4364
Petykemano
veterán
Ueda
#4363
Petykemano
veterán
A big.LITTLE, vagy hibrid multithreading szerintem nem elsősorban a magszám növelhetőségét célozza.
Szerintem arról van szó, hogy
1) vannak olyan szoftverek, amik 1 szálon, vagy legalábbis kevés szálon tudnak tudnak csak működni. Viszonylag kevés az olyan szoftver, ami sok magra egyenletesen skálázódik. A játékok egy olyan köztes terület, ahol ügyködnek a több magra való skálázódáson, de mindmáig meghatározó az, hogy a 1-2-3 szálon mennyire erős egy processzor.
2) az IPC növelése jelentős fogyasztás és területigénnyel rendelkezik. (valószínűleg a frekvencia növelése is)És a lényeg: ahhoz, hogy azoknál a programoknál teljesítménynövekedést érjenek el, amik rosszul skálázódnak, az IPC-t kell növelni. De azoknál a programoknál, amik jól skálázódnak a magok számával, nem feltétlenül szükséges az összes szál kezeléséhez magas IPC-jű mag. Azokhoz a programokhoz, amelyek jól skálázódnak, előnyösebb lehet 1 magas IPC-jű mag helyett 2-3 olyan, aminek az IPC-je 30%-kal alacsonyabb, de negyedakkora helyet foglal és negyedannyit fogyaszt.
Tehát a kényszer nem a magszám növelésének irányából jön, hanem az IPC növelés tranzisztor és energia költségeiből, amit azokban az esetekben, amikor több magot ki tud használni egy applikáció, hatékonyságra optimalizált magokkal kompenzálnak.
Nekem úgy tűnik, hogy az intel ezt az utat választotta. Nem állítom, hogy ez a helyes.
-
joysefke
veterán
Konkért példa, x265 kódolás, 4 mag avx2-vel vagy 6 mag avx/2 nélkül
Ez Sse4.2 vs Avx2? Mert ebben az esetben az Avx2 alternatívája (Sse4.2) is vektorkód. Az 50%-os gyorsulás pedig kb hihető az Avx regiszretek szélességéből (+100%) adódóan.
Ha az Avx2 "alternatívája" a sima skalár kód, akkor nem, nem tudod /aligha tudod több maggal a vektorkódot helyettesíteni. Nem branchelő/branchelést kiküszöbölő kódnál akkora gyorsulást tud hozni az Avx2, hogy egy Avx-es szál lenyomhat nyolc skalárt.
A kérdés nekem az, hogy az Avx512 ad-e annyi plusszt az Avx2-höz képest, hogy az alkalmazásfejlesztőnek megérje a vesződséget.
Új hozzászólás Aktív témák
Hirdetés
- Debrecen és környéke adok-veszek-beszélgetek
- Milyen routert?
- Samsung Galaxy S25 - végre van kicsi!
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Posta, csomagküldés
- Háztartási gépek
- Nintendo Switch 2
- Apple iPhone 16 Pro - rutinvizsga
- PlayStation 5
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- További aktív témák...
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest