Hirdetés
Új hozzászólás Aktív témák
-
lenox
veterán
Hiába létezik ma olyan mag, amelybe fizikailag 512 bites SIMD motor van beépítve, ha ahhoz nem érhető el a kihasználást lehetővé tevő utasításkészlet, vagy maga a program nem tud vele mit kezdeni.
Hat ez meg mindig nem jo, milyen cpu van 512 bites SIMD motorral, amihez nincs utasitaskeszlet, csak ugy ott van?
De amugy ha jol ertem azt akarod mondani, hogy milyen erdekes, ha az utasitas es a fizikai feldolgozas vektorhossza nem fugg egymastol. Annyi bajom van amugy ezzel, hogy az intel mar csinalt SSEx-et 64 bites, az amd meg AVX-et 128 bites feldolgozassal, meg biztos van mas pelda is, szoval ebben semmi uj nincs, nem hinnem, hogy barmi akadalya lenne, hogy pl. az intel 512 bites AVX-et csinaljon celeronokban 64, pentiumokkal 128, i3-i5-i7-eknel 256, xeonoknal 512 bites feldolgozassal, csak ok marketing okokbol mashogy csinaljak. De amugy emlithetnem az vektorprocesszorokat, pl. a Cray csinalt ilyeneket. Nyilvan zsenialis volt akkor.
-
#20
Balala2007
tag
Fiery
#9
Balala2007
tag
Az AVX2 valojaban az, ami kimaradt az AVX-bol: 256 bites integer vektorok kezelese es FMA.
Ez igy nem pontos, az FMA nem resze az AVX2-nek, nem veletlenul kapott kulon feature bitet a CPUID-ben.
Van FMA-s proci AVX2 nelkul (pl. Piledriver), meg AVX2-es FMA nelkul (pl. Via CNR). -
#19
Balala2007
tag
Petykemano
#8
Balala2007
tag
válasz
Petykemano
#8
üzenetére
lehetne-e egy hasonló hardvert készíteni x86-os prociban, ami a különböző szélességű avx, avx 2, stb lekezeli?
AVX512VL: 128, 256, 512b modok szimmetrikus tamogatasa,
ez a k12-ben és vagy zenben visszaköszönhet?
Skylake szerverben benne lesz.
-
#18
Balala2007
tag
Abu85
#15
Balala2007
tag
Ez érthető, hiszen például egy AVX-re lefordított program nem fut AVX2 módban az ezt támogató processzorokon.
1, nincs "AVX2 mod"
2, fut
3, xmm regiszterek nem hasznaljak a high-lane-t (255-128b)
4, ha van extra EU, akkor a fuggetlen low-lane-ek mehetnek parhuzamosan (pl. SKL integer xmm AVX throughputja jobb, mint a BDW-e) -
Fiery
veterán
Semmivel nem lett jobb. Nincs olyan, hogy AVX2 mod. Olyan van, hogy virtualis 8086 mod, de se AVX mod nincs, se AVX2 mod. Inkabb torold ki az ominozus mondatot, me'g az is jobb, mintha tovabb faragod, es minden javitassal csak tovabb asod magad alatt a godrot. Nem gond, ha nem vagy programozo, de (szakmai) ujsagirokent az adott tema ismerete azert kotelezo lenne. Vagy ha nem ertesz hozza ilyen melysegeben, akkor inkabb ne irj a temarol semmit, mert ez lesz a vege...
-
lenox
veterán
Ez érthető, hiszen például egy AVX-re lefordított program nem fut AVX2 módban
Mondjuk jobb nem lett. Mi az, hogy AVX2 mod? Ha elinditod az AVX-re forditott programot egy AVX2-t supportalo cpun csak siman futni fog, pont, mintha csak AVX-et supportalna a cpu. SSE es AVX kozott van olyan, hogy ha kevered oket, akkor performance penalty lesz, ha nem vigyazol.
-
#14
lenox
veterán
Plasticbomb
#12
lenox
veterán
válasz
Plasticbomb
#12
üzenetére
Ketszer is azt irta, hogy AVX2-re kell leforditani. Ha azt akarta volna mondani, hogy az AVX2 kod nem fut a csak AVX-et tamogato processzoron (ami a helyes lett volna), akkor azt irta volna, hogy ja tenyleg, koszi, javitom. De nem, azt irta, hogy az AVX-et kell AVX2-re leforditani, ez meg igy tevedes.
Mondjuk abba ne is menjunk bele, hogy az AVX2 leginkabb integer az AVX meg float utasitasokat tartalmaz, tehat az AVX2 kodbol leginkabb SSEx utasitasok lesznek, ha az AVX2-t nem, de az AVX-et meg tamogato processzoron akarnad futtatni, (merthogy az AVX-et tamogato processzorok SSEx-et is tamogatnak), de maradjunk csak annal a resznel, hogy ami AVX2-t tamogat, az AVX-et is, tehat ha AVX kodot futtatnal AVX2-t tamogato cpu-n, akkor az siman menne. -
#13
Fiery
veterán
Plasticbomb
#12
Fiery
veterán
válasz
Plasticbomb
#12
üzenetére
A CPUID utasitas pont arra szolgal, hogy egy adott szoftver egyszeruen tudja detektalni a rendelkezesre allo x86 utasitaskeszlet kiegeszitesek megletet. Kulon van bit az AVX-re es az AVX2-re. Mint ahogy kulon van SSE-re, SSE2-re, SSE3-ra (stb) is. Eddig is teljesen hetkoznapi volt az, hogy egy adott processzor nem mindegyik ilyen kiegeszitest tamogatja. Nem kell kulonleges technika vagy trukk ahhoz, hogy egy szoftver tamogasson AVX-et es AVX2-t is, de ha csak az egyik tamogatott a hardver altal (pl. Ivy Bridge vagy Kaveri), akkor is helyesen mukodjon.
-
#12
Plasticbomb
addikt
Fiery
#9
Plasticbomb
addikt
Ez a téma már kiesik az én jelenlegi tudáskörömből, de nem lehet, hogy azt szerette volna mondani, hogy nem minden avx támogató processzor támogatja az avx2-t? Tehát ami csak avx-et ismer, az esetenként nem tud mit kezdeni az avx2 kóddal? Így nézve (Az én e témában ismeretlen fejemnek) logikusan néz ki, amit mondott/írt.
-
Bundyta
tag
Akkor vagy nem assembly az eredmény, vagy valami trükközés van, pl van egy ütemező, s aztán az "fordítja" tovább a kódot a vektormagoknak.
Ezt nem egészen értem. Ezek szerint assembly-ben nem is kell programozni, mert a fordító kigenerálja az ass kódot? Vagy valamilyen p-kódra fordít, amit egy HAL tovább fordít gépi kódra a hw-re?
-
Lehet arra gondolt, hogy újra kell fordítani, hogy kihasználja az AVX2 új feature-jeit. Mondjuk így meg az kérdéséses, hogy az SVE-nél mégis hogy lehet az, hogy olyan új SIMD feature-t is támogat a lefordított szoftver, ami még nincs.
Akkor vagy nem assembly az eredmény, vagy valami trükközés van, pl van egy ütemező, s aztán az "fordítja" tovább a kódot a vektormagoknak. Így effektíve GPU-szerű a felépítés, gyakorlatilag kapunk egy utasításkészlet szinten integrált APU-t, amiben a "GPU" simán assemblyvel, mindenféle plusz trükkel vagy API nélkül munkára fogható. -
Fiery
veterán
Tudod, hogy csiplek Abu, de most nagyon mellelottel. Konkretan ertelmetlen, amit irtal.
Az AVX2 nem kiterjeszti az AVX-et, hanem kiegesziti. Marhara nem mindegy. Ha az AVX 256 bites lebegopontos vektor utasitasokat jelentene, az AVX2 pedig ugyanazt, de 512 bites vektorokkal, akkor azt mondom, igazad van, jol irtad. De kozel sem ez a helyzet. Az AVX2 valojaban az, ami kimaradt az AVX-bol: 256 bites integer vektorok kezelese es FMA. Az AVX az AVX2-vel lett teljes, komplett 256 bites vektor utasitaskeszlet. Amit AVX-re "leforditottal" (mar ez a kifejezes is tul pongyola), az vigan fog mukodni egy AVX2-t tamogato processzoron, mar csak azert is, mert minden AVX2-t tamogato processzor tamogat AVX-et is
Hatranya pedig nem lesz a szoftvernek abbol, hogy mondjuk alatta valaki kicsereli az Ivy Bridge-et Haswellre.Jobb analogia lehetett volna _talan_, ha az SSE2 vs. AVX-et hozod elo: ha egy szoftver csak 128 bites (SSE2) vektor utasitasokat hasznal, akkor valoban 50%-ban hasznalja csak ki az AVX-es processzorok kepessegeit.
A hirhez pedig: lehet, hogy papiron jol nez ki ez a cucc, de lattunk mar nehany "zsenialis" ARM probalkozast a szerver piacon (me'g az AMD is probalkozott ezzel), es egyelore _semmi_ kezzel foghatot nem tudnak a gyartok felmutatni. Varjuk meg, amig megjelenik kesztermek formajaban, es elkezdi pusztitani a Xeonok (es addigra mar a Zen Opteronok) piacan a "csoffadt" AVX2-es szerver procikat
-
#8
Petykemano
veterán
Petykemano
veterán
Ez most egy olyan kiterjesztés, mint az avx, avx 2 x86-hoz, amiben programozni kell, és amelyet egy megfelelő hardverrész értelmez és.végrehajt?
Oda akarok kilyukadni, hogy lehetne-e egy hasonló hardvert készíteni x86-os prociban, ami a különböző szélességű avx, avx 2, stb lekezeli?
Oda akarok kilyukadni, hogy ha ez már amúgy is nagyon hasonlít gpgpura, lehetne egy ilyen hardver az igp? Meg lehetne-e oldani, hogy avx és avx2 stb utasításokat offloadolni a simdben amúgy is erős memória és cache koherens igpnek?
Figyelembe véve, hogy keller arm fan, ez a k12-ben és vagy zenben visszaköszönhet?
-
lenox
veterán
Barmilyen AVX hatrany hogyan befolyasolja azt a tenyt, hogy minden AVX2-t supportalo cpun fut az AVX kod, tehat rossz a pelda?
Amugy meg AVX is fut 128 bites feldolgozokat tartalmazo cpun, vagy SSE 64 bitesen, szoval ez nem egy uj dolog, ami sokkal erdekesebb, hogy a gpuk sokkal szabadabb adateleresi mintat tudnak teljes sebesseggel, cpun meg kb. barmit akarsz, rogton sokkal lassabb, en ezzel szoktam legtobbet tokolni.
-
Ueda
senior tag
GPGPU szemszögéből kell nézni az AVX hátrányait. Amúgy ez tök igaz, hisz az Xvid kodek sem fut AVX-n, csak hogy egy gyakorlati példát mondjak. Viszont egy GPU-ra írt kodek a kártya teljesítményével arányos sebességgel fut. Régi probléma ez, már az ókori görögöket is foglalkoztatta.
-
#2
Abu85
HÁZIGAZDA
Balala2007
#1
Abu85
HÁZIGAZDA
válasz
Balala2007
#1
üzenetére
Le kell fordítani AVX2-re is, hogy AVX2-n fusson.
-
#1
Balala2007
tag
Balala2007
tag
hiszen például egy AVX-re lefordított program nem fut AVX2-n.
Mivan????
Akkor vagy nem assembly az eredmény, vagy valami trükközés van, pl van egy ütemező, s aztán az "fordítja" tovább a kódot a vektormagoknak. Így effektíve GPU-szerű a felépítés, gyakorlatilag kapunk egy utasításkészlet szinten integrált APU-t, amiben a "GPU" simán assemblyvel, mindenféle plusz trükkel vagy API nélkül munkára fogható.
Hatranya pedig nem lesz a szoftvernek abbol, hogy mondjuk alatta valaki kicsereli az Ivy Bridge-et Haswellre.
Új hozzászólás Aktív témák
ph A vállalat hardveresen oldja meg az aktuális SIMD utasításarchitektúrák legnagyobb gondját.
- ASUS 18W USB ADAPTER
- Samsung Galaxy A03 64GB, Kártyafüggetlen, 1 Év Garanciával
- 122 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- MacBook, Apple M1 / M2 kompatibilis dokkolók, DisplayLink 4K, USB-C, Type-C
- iPhone 15 Pro 128GB, Szép állapot, Független, 100%, Garanciával!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest