hiszen például egy AVX-re lefordított program nem fut AVX2-n.

Mivan????

AIDA64.com

Le kell fordítani AVX2-re is, hogy AVX2-n fusson.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Nyilvan nem AVX2-n fut, hanem processzoron, ami ismeri az AVX2-t. De melyik az a processzor, ami tud AVX2-t, de nem tud AVX-et?

Amelyik nem zseniális

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

Akkor en csak zsenialisat ismerek.

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.

OS : EndeavourOS KDE . . . . . . Parancs menü : https://pastebin.com/u/txt444

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.

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?

Találgatunk, aztán majd úgyis kiderül..

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

[ Szerkesztve ]

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ó.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

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?

A pénz nem boldogít. Pláne, ha nincs.

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.

[ Szerkesztve ]

ArchLinux, Star Citizen, Subnautica+BZ, ASTRONEER, Grounded, DRAG, VOLCANOIDS, Space Engineers, Elite:Dangerous, Beyond Blue (TK-Glitch Proton)

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.

[ Szerkesztve ]

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.

[ Szerkesztve ]

Egyértelműsítettem a kérdéses mondatot.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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.

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...

[ Szerkesztve ]

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)

AIDA64.com

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.

AIDA64.com

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).

AIDA64.com

Átszerkesztettem jobban. Kitörölni nem akarom, mert ez a kulcstényező, hogy miért jobb az ARM megoldása.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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.

Skylake Core generáció

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

De az engedelyezve nincs, gondolom nem az a zsenialis ujitas, hogy engedelyez valaki valamit, ami amugy letezik...