Új hozzászólás Aktív témák
-
ddekany
veterán
Furcsa, hogy ennyire nem érdekelte az Intelt, hogy lehetővé teszi az OS-nek, hogy adott szálra, amit az OS csak nagy magra fog tenni, engedélyezze. Legalább is nehezen tudom elképzelni, hogy egy ilyen feature jelentősen növelné az CPU komplexitását.
-
-
ddekany
veterán
Mondjuk ha onnan indult, akkor eleve tudta az OS, hogy csak nagy magra szabad ütemezni (hacsak nem simán szerencséje volt). Elvileg lehetne azt, hogy AVX-512 az mindig tiltott, kivéve, ha az OS kifejezetten azt közölte a CPU-val, hogy most ezen a szálon szabad. Viszont a tiltás részhez kéne valami AVX-512 enabled flag a CPU-ba hardware szálanként, gondolom én, az meg tán nincs.
Az hogy ennyire nem mentek erre rá, bennem azt veti fel, hogy hosszú távon talán meg is akarják takarítani a lapjáról az AVX-512-et (most csak viszi a tranzisztort), csak most még inkább hagyták úgy, ahogy a Xeonba is kell.
[ Szerkesztve ]
-
ddekany
veterán
Nincs ilyen a munkámban, szóval nem tudom, de ez valószínűleg nem ilyen egyszerű. Az alkalmazás már akár induláskor tudni akarja, van-e AVX-512 támogatás, mert ettől függ, hogy később egyes funkcióknak melyik megvalósítását fogja hívni. Ennek a lekérdezése még nem exception, sőt, valószínűleg azt se tudod, hogy ez le lett kérdezve (mert csak CPUID utasítást hív, aztán franc tudja a visszaadott értékben mit nézett az alkalmazás). Én azt tudom első körben elképzelni, mint minimális megoldást, hogy a felhasználó vagy az alkalmazás telepítő szépen bejelöli az executable-re, hogy allow big core features. Akkor a CPU azt fogja reportálni, azokban a szálakban(!), hogy van AVX-512 (-nek ilyen-olyan subsetje), míg másokban azt, hogy nincs, akkor is, ha véletlenül épp nagy magon vannak. És ehhez kéne a CPU-ban támogatás, mert, gondolom, itt akkor a CPUID utasításnak kéne száltól függően más-más értéket adnia. Vagy, hogy tudjon az OS trappot tenni a CPUID utasításra, és így manipulálni az eredményét.
[ Szerkesztve ]
-
ddekany
veterán
Igen, ezt mondtam, hogy alapból nem lenne AVX-512, de annyiban lenne jobb mint most, hogy ha valakinek tényleg hiányzik, akkor még vissza lehetne kapcsolni alkalmazás szinten. Aztán mindenki eldöntheti, hogy neki abban az alkalmazásban megéri-e az E-s magok elveszítése az AVX-512-ért cserébe.
Amúgy ha igazán komolyan vennék, akkor már direkt heterogén CPU-kra felékszült alkalmazás verziókban lehetne, hogy "bool avx_512_available = some_os_api::stick_to_core_that_supports_feature_if_avilable(AVX_512);", és akkor az alkalmazásnak csak az ezt hívó szála fog big core-hoz ragaszkodni, és a többi továbbra is mehetne little-re is. Szóval CPUID-vel piszmogás helyett az OS-től kéred le a feature elérhetőséget, és egyben kéred az OS ütemezőjét, hogy csak oda rakjon ahol az elérhető, ha valahol elérhető.
De mint mondod, valószínűleg ki akarják totál vezetni az AVX-512-t desktopon, hogy felszabaduljon a helye valami hasznosabbra, ezért nincs ilyen.
[ Szerkesztve ]
-
ddekany
veterán
A szálakat az OS osztja le a magokra, és szálak közötti időmegosztásos kapcsolgatás is az OS feladata (kivéve a hyperthreading esetében, de az OS szempontjából 1 helyett 2 mag lényegében). Szóval ha lehet az OS-el közölni, hogy ezt a szálat csak nagy magra lehet, akkor nincs ebben semmi kezelhetetlen. Csak gondolom nem akarják az egészet desktopon.
Új hozzászólás Aktív témák
- iPhone topik
- SSD kibeszélő
- Anime filmek és sorozatok
- Projektor topic
- Kínai, és egyéb olcsó órák topikja
- Milyen TV-t vegyek?
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Befutottak az első Xperia 1 VII pletykák
- Honor Magic5 Pro - kamerák bűvöletében
- Yettel topik
- További aktív témák...