- Azonnali informatikai kérdések órája
- 5.1, 7.1 és gamer fejhallgatók
- OLED TV topic
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Projektor topic
- Hobby elektronika
- Exkluzív funkcióval tenné vonzóbbá az ARM-os PC-ket a Microsoft
- Milyen egeret válasszak?
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Vezetékes FÜLhallgatók
Hirdetés
-
Megjelent a Moondrop audio-fókuszú telefonja Kínában, lesz globális verzió is
ma Középkategóriásak a specifikációk, ha az SoC-t és a kamerákat nézzük, de itt a kiemelt figyelem a hangra összpontosul, abban pedig egyedi dolgokat kínál a készülék.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Stellar Blade - Befutottak az első tesztek
gp A beszámolók alapján talán elmondható, hogy a stílus kedvelőinek érdeme lehet beszerezni a teljes kiadást.
Új hozzászólás Aktív témák
-
válasz Cathulhu #2620 üzenetére
Nem értem hogy egyáltalán min vitatkozunk. Azt sem értem, hogy mi a problémád az unrollingra írt két mondatommal.
Ha jobban tudod, hogy mi az unrolling, akkor kérlek írd le, hogy hol a probléma a kijelentésemmel és ne wikipediát idézz, mert én akkor meg a Mestert idézem: https://www.agner.org/optimize/optimizing_cpp.pdf (c.h 12.3)
Tehát még egyszer: A loop unrolling sok minden optimalizációra (lehet) jó, ezek közül az egyik, hogy lehetőséget ad(hat) automatikus vektorizálásra, mivel több (2-4-8-16 attól függően hogy mennyi adatelem fér egy vektorba) skalár adaton végzett ciklustörzset egyesít egy nagyobb ciklustörzzsé, ahol az egy-egy skalár adaton végzett műveletet helyettesíteni lehet nagyobb vektorműveletekkel.
Lehet hogy te arra gondoltál, hogy egy konstans hosszúságú loop
Ahhoz hogy ez a fordító által automatikusan megvalósítható legyen a kódnak egyszerűnek kell lennie: az egymás után következő ciklusok között csak könnyen feloldható függőség lehet. Bonyolult függőségeket és branchelést nem fog tudni magától feloldani/kezelni a fordító.
Attól függetlenül, hogy a compiler bizonyos egyszerű skalár kódrészleteket (pld for ciklussal egyenként végiggyalogolok egy tömb összes elemén és hozzáadok az aktuális elemhez valami konstansot) hatékonyan tud vektorizálni, ennek még zéró köze van egy SIMD- utasításokat használva kézzel optimalizált kódhoz.
Erre mondtam azt, hogy ha Pistike ír mondjuk egyszerű képmanipulációs szoftvert skalár műveletekkel, mondjuk egy Sepia filtert, ami ugye az egyik legegyszerűbb RGB adatokon dolgozó algoritmus, a compiler nem fog tudni a skalár kódból érdemi SIMD kódot generálni.
Az ok pedig annyi, hogy a hatékony SIMD kódhoz elengedhetetlen, hogy a bemeneti és köztes adatok struktúráját hozzáigazítsd a vektoros feldolgozáshoz. Ez nagy munka. Az RGBA adatokat pld transzponálni kell, hogy a bemeneti [RGBARGBARGBARGBA] helyett kapj valami ilyet:
[RRRR] [GGGG] [BBBB] [RRRR] [GGGG] [BBBB] stb stb (az A alapvetően nem kell a szépiához).Aztán ott van a branchelés. Ha a módosított képen valamelyik színkomponens nem 0-255 közé esik, akkor csonkolni kell. Ezt sem fogja tudni érdemben automatikusan skalárról vektorra fordítani a compiler.
stb stb stbAz MKL az intel sajat, zart forrasu kodja, kb termeszetes, hogy bunteti a nem intel procikat
Nem, nem természetes. Itt arról van szó, hogy ha a dispatcher nem intel procit detektál, akkor rá sem engedi az AVX2 kódra, akkor sem, ha a proci egyébként támogatja azt.
Ennyi erővel az intel fgv könyvtárak akár az x86-os kódot is tilthatnák AMD-n.
Egyébként attól, hogy egy kódot AVX2 -t használva írtak meg, az még nem lesz önmagában ideális egyszerre Skylakere és mondjuk ZEN2-re.
Az intel nyilván a saját AVX2-t tudó processzoraira fogja az AVX2 -t használó kódrészletet optimalizálni. Figyelembe veszi az L1/L2 cache méretét asszociativitását, adott SIMD utasításból hányat tud egyszerre végrehajtani a mag és mekkora az utasítás késleltetése stb. A sebességet mérik is, és nyilván úgy csiszolják, hogy a legjobb legyen a saját procijuknak. Tehát az AMD proci itt is hátrányban lenne, de legalább nincsen szándékosan kigáncsolva. (mintha skalár kódot futtatna enyhén szuboptimális vektorkód helyett)Tehát én azt várnám el az ilyen gyártói fgv könyvtáraktól, hogy ha a konkurens processzor tudja a szükséges utasításkészletet, akkor az is fusson rá az optimalizált útvonalra.
A fenti hosszú irományom lényege pedig az, hogy semmilyen compiler nem fog saját kútfőből skalár kódból vektor kódot csinálni eltekintve pár low hanging fruit leszedésétől.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-
- Intel I5 13600KF 14mag/20szál - Új, Tesztelt - Eladó! 89.900.-
- 100db 4WORLD - 08529 - SATA3 KÁBEL 45CM - RED Új
- Sony PlayStation 5 (PS5) Játékkonzol csomag
- SK Hynix Platinum P41 2 TB M.2 NVME PCI-E 4.0 x4 - Új, Tesztelt - 7000-6500 MBs - Eladó!
- Patriot Viper 3000mhz ddr4 memória (32gb) dobozos cl16 Csere
- Kukirin G3 elektromos roller (1200W, 50-70 km hatótáv, 50 km/h végsebesség)
- 2db 1TB hibás 2.5" SATA Samsung notebook HDD
- Sound Blaster AWE64 ISA hamgkártya
- SteelSeries Rival 600 USB fekete gamer egér, (nem használt, bontott csomagolás) - vállalkozástól