- Vivo X200 Pro - a kétszázát!
- Magisk
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Samsung Galaxy A56 - megbízható középszerűség
- Yettel topik
- Telekom mobilszolgáltatások
- Samsung Galaxy S25 - végre van kicsi!
- Okosóra és okoskiegészítő topik
- Három Redmi 15 érkezett a lengyel piacra
- Android alkalmazások - szoftver kibeszélő topik
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Nagyon nem futnak rajta optimálisan a vektorok, ha nem a célzott szélességű hardver van a magban. Rengeteg kézi finomhangolás kellene, amit kb. senki sem akar megcsinálni.
Az SVE abból a szempontból van fényévekkel az AVX előtt, hogy nincs is definiálva a vektormotor hossza. A programozó nem is tudja ezt, és nem is dolgozhat egy bizonyos hosszra. Tehát a hardver oldalán mindegy, hogy 128 bites vagy 2048 bites a vektormotor hossza, mindenféle alacsony szintű finomhangolás nélkül lineárisan skálázódik ugyanannak a kódnak a teljesítménye az egyre szélesedő vektormotorral. Az AVX erre megközelítőleg sem képes. Ilyen formában tök hasztalan vagdalni.
Az alapvető probléma az, hogy az AVX koncepció szintjén nagyon durván el van baszva az alapoknál. Ha valami skálázhatót akarunk, akkor az AVX-et úgy ahogy van ki kell dobni a kukába.
Volt egyébként az x86/AMD64-es magoknál erre megoldás az XOP-vel. Az alapjaiban egy nagyon átgondolt, skálázhatóságra tervezett rendszer volt, csak senki sem támogatta. Most nyilván már erősen visszasírja az ipar, látva azt, hogy az AVX-512-vel nem lehet mit kezdeni.
-
ddekany
veterán
Gondolom nem lenne olyan szempontból értelme, hogy az AVX2-es megvalósítása egy funkciónak kicsit gyorsabb lenne, mint keskeny feldolgozós AVX-512 megvalósítása. Persze értem, kompromisszum, mert viszont ha nagy magra jut a szál, akkor meg gyorsabb. De ez lehet egy ok, amiért nem voltak erre motiváltak.
A másik, hogy az új és kiszélesített regisztereket megvalósítását nem tudod megúszni azzal, hogy a feldolgozás keskenyebb. De nem tudom mennyi overhead ez egy little CPU-ban, lehet nem sok, de ez is bosszantó. Meg nyilván a fele szélességű AVX-512 megvalósítás többi része is visz extra tranzisztorokat.
Ránéztem SVE-re. Alapvetően kihat az utasítás készletre az, hogy a binárisnak ne kelljen feltételeznie semmilyen feldolgozó szélességet, és mégis minden optimálisan legyen "felszeltelve".
-
thgergo
tag
Ebben azt nem értem, hogy az AVX-512 nél miért nem tehető meg, hogy felbontódik két vagy sokkal több órajelciklusra a művelet 64/128 bites egységeken, már a kezdeti bevezetés óta celeronon, pentiumon is. A cél a bináris kompatibilitás lenne, hogy akár emulálva mehetne a kis magokon is, akár 10-ed sebességgel.
Lehet ez szoftveres is, pl. egy preload script az AVX-et tartalmazó részleteket, SSE és más nem optimális műveletre cseréli a futatás előtt. Ez azért szerintem sokkal egyszerűbben menne mint arm->i386 esetén az Apple Rosetta... -
ddekany
veterán
Az SVE2 (ahogy itt halottam) direkt olyan, hogy lehet belőle sebesség rovására kevésbé széles megvalósítást betenni, ami gondolom nem eszik túl sok területet meg egy little magban. Ha ez AVX-512-nél ez nem működik... akkor ennyi volt, nem lehet mindenhol elérhető, mivel most már az Intelnél is fontosak lettek a little magok.
-
LordX
veterán
Most annak, hogy mennyire szar az AVX-512 (függetlenül, hogy igaz), semmi köze nincs ahhoz, hogy az Intel a termékei töredékébe rakja be az "új" kiterjesztést. Ha nincs processzor, ami futtassa, senki nem fog fejleszteni rá. A Tigris Tó előtt ez még a 13 éves AVX(1)-re is igaz volt, mert Celeron / Pentium.
Meanwhile ARM SVE2 jövőre minden programban benne lesz, mert az A510 is tudja, így egy abszolút trash 4xA510 SOC-vel is megy majd, nem csak a flashy QCOM 8G1 meg MTK D9000-rel.
-
Abu85
HÁZIGAZDA
Mert az ARM SVE a GPGPU-tól lop ötleteket, és nem olyan hígfos, mint az AVX-512. Konkrétan skálázható a rendszer, így ugyanarra az ISA-ra építhetsz olyan magot, amiben 128 bites SIMD van, és olyat, amiben 2048 bites. Eközben pöcre ugyanazt a kódot eszik meg, sőt, közel lineárisan skálázódó teljesítményt adnak vele. Az AVX-512 nem ilyen rugalmas, így azt baszhatja az Intel.
-
LordX
veterán
A nobody cares az valószínűleg nem azért van, mert az utasítás-készletek szarok (ugye az AVX-512 az valójában 12 különböző pakkot jelent), hanem mert:
- This shit (ja, ez 3 éves. Azóta még rosszabb.)
- Nincs a magból consumer proci, csak szerver.
- Még ha a mag tudja is, az ~összes consumer prociban le van tiltva. Kivéve egy i3-as ultramobil chipben.
- Le van tiltva az E core miatt. Az AVX-512-FP16 csakis és kizárólag letiltva létezik az Alder Lake P core-jában. De legalább a VNNI 256bites változatát belerakták az E-core-ba.Tök mindegy mit tud, ha nem elérhető, nem fog rá programozni senki.
-
LordX
veterán
A pakoljunk össze marha sok "Atom" processzort az de milyen jól bejött az Intelnek a Larrabee-vel meg a Xeon Phi-vel is.
-
thgergo
tag
Mi köze van a Cooper Lake-P -nek és a Cascade Lake-AP-nek egymáshoz?
Mindkettő a Cascade Lake-SP-nek a fejlesztése de az irány teljesen más:
- Cascade Lake-AP: Valójában egy 4 utas szerver, de egybetokoztak 2 db 28 magos cpu-t, így 2 utasként nevezhető. Azonban nem fogyaszt kevesebbet mint egy valódi 4 utas, sem nem olcsóbb ugyanannyi UPI link kell bele, ráadásul a hűtése is egyedi. Cooper Lake-SP is ugyanez lett volna, de már normál hűtéssel + sockettel, de ez sem mutathatott nagyobb perf/W értékeket. Akkor meg minek az egész ha nem jobb, az ügyfelek továbbra is Cascade Lake-SP-t vesznek, jóval olcsóbban.
- Cooper Lake-P: Duplázott UPI linkek a processzorok közt kevesebb PCIe árán, 4-8 utas szerverekhez, de 2x annyit fogyaszt az interconnect. Eléggé rétegigény, ahol ez számít, és meg is érik az árát mission critical helyeken, pl. HPE Superdome 280... Nem hiszem, hogy bárkinek is eszébe jutott felhőalapú adatközpontokba ilyet tenni Cascade Lake-SP helyett, ahol a sűrűség, hatékonyság és (olcsóság) számít.Nem hiszem, hogy a Cooper Lake-P helyettesítő terméke lett volna a Cascade Lake-AP-nek valaha... Nem Cooper Lake-SP-re gondolt a cikkszerző Cooper Lake-P helyett?
-
Duck663
őstag
"Úgy tudjuk, hogy itt a Alder Lake E-Core-jainak jelentősen kigyúrt továbbfejlesztéseit fogja használni az Intel..." akkor se SMT nem lesz, se újabb utasításkészletek. De legalább szép számokat mutat majd magszám tekintetében és vállalható fogyasztása lesz.
Nem igazán értem az Intelt, minek az újabb, hatékonyabb utasításkészletek fejlesztése, ha utána kivágják vagy letiltják a CPU-kban. El kellene már dönteni, hogy most, hogyan akarnak teljesítményt növelni, jobb utasításkészletekkel, vagy több maggal.
Új hozzászólás Aktív témák
Hirdetés
- Intel Core i7-10700 8-Core 2.9GHz LGA1200 (16M Cache, up to 4.80 GHz) Processzor!
- Intel Core i5-14500 14-Core 2.6GHz LGA1700 (24M Cache, up to 5.00 GHz) Processzor!
- Intel Core I5-8600K
- Intel Core i7-12700 12-Core 3.6GHz LGA1700 (25M Cache, up to 4.90 GHz) Processzor!
- Eladó Garanciális (2027.10.08) AMD 7700 processzor Jegelve: torok.adam11
- Samsung Galaxy S25 128GB Kártyafüggetlen 1 év Garanciával
- Eladó egy XMG P406 laptop
- BESZÁMÍTÁS! Asus TUF B360-Pro i7 9700 16GB DDR4 512GB SSD RTX 4060 8GB ZALMAN S3 TG Zalman 500W
- BESZÁMÍTÁS! MSI B450M R3 3100 16GB DDR4 120GB SSD 1TB HDD GTX 1050 Ti 4GB ZALMAN S2 TG Chieftec 500W
- BESZÁMÍTÁS! GIGABYTE B550M R5 5600 32GB DDR4 512GB SSD RTX 2070 SUPER 8GB ZALMAN I3 NEO Enermax 650W
Állásajánlatok
Cég: FOTC
Város: Budapest