- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Milyen cserélhető objektíves gépet?
- ZIDOO médialejátszók
- Azonnali informatikai kérdések órája
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Autós kamerák
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Gaming notebook topik
- Milyen videókártyát?
Hirdetés
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
-
Megjelenési dátumot kapott a Star Wars: Hunters
gp A tervek szerint június elején végre befut a teljes kiadás mobilokra/tabletekre és Nintendo Switch-re.
Új hozzászólás Aktív témák
-
LordX
veterán
válasz hugo chávez #129 üzenetére
Az x86-al az elavult, nem épp multiprocesszor-barát memóriamodellje a baj. Az Itanium gyönyörűen megcsinálta jól, csak a VLIW ölte meg. A következő, aki ezt megcsinálta, az az ARMv8 (ott az acquire-release helyett SC atomics van, egyesek szerint még jobb).
-
LordX
veterán
válasz hugo chávez #133 üzenetére
Nem tudom hogy vagy vele, de PC és mobil vonalon minden chipben max 8 szál (4 x86 mag HT-vel vagy 8 ARM mag) van, mellette egy akkora iGPU-val, ami már több helyet foglal a chipen, mint a 4/8 CPU mag és a cache összesen. Szóval a gyártók szerint sincs (ma) gyakorlati értelme erre a piacra. Szerverekbe meg gyártják a 36 szálas Haswell-EX-et meg a 48/64/192 magos ARM chipeket GPU nélkül
Lehet kiegészíteni x86 modellt; a TSX utasításkészlet egy ilyen próbálkozás (bár nem abban az irányban, hogy közeledjen az ARM felé), csak azért talán mutatja, hogy egy ilyen kiegészítés mennyire nehéz vállalkozás, hogy az Intel is el is cseszte a TSX első implementációját. Az se segít, hogy az x86-ban gyakorlatilag minden utasítás load/store utasítás, ha az első operandus memóriacím.
Szerintem ez a TRIPS nem próbálja megoldani ezt a problémát; Ők "csak" azt kutatják, hogy hogyan lehetne ILP növekedést elérni, és szerintük a megoldás az, hogy az OoO helyett implicite kódoljuk bele az utasításkészletbe. Hol is láttam ilyet..
-
LordX
veterán
Nem a read-modify-write, hanem "csak" a read és a write rész külön-külön atomi, ha a felhasznált adat teljesen befér egy cache line-ba (azaz nem lép át 64 byte-os címet) - ez P6 óta van, előtte csak aligned hozzáférés volt atomi. De ez igazából teljesen mindegy, mivel a főmemóriával és a többi processzorral való "kommunikáció" amúgy is cacheline szinten megy. Lásd [1], 8.1 fejezet.
A probléma az ordering: [1] 8.2.2 Van egy zsák szabály, hogy milyen memóriaművelet mivel lehet felcserélni, de ha megnézed a fejezetet, kb. az jön le, hogy semmit semmivel - kivéve pár esetet - még akkor is, ha egyébként teljesen független memóriacímmel dolgozik az érintett művelet. Ez már egyprocesszoros rendszernél is problémás: Out-of-Order működésnél komoly probléma, ha tilos átrendezned műveleteket. Többprocesszoros rendszerben meg amikor egyik utasítás egy lassú szinkronizációs művelet, a többi utasítás is blokkolva van: egy LOCK INC több, mint 100 órajel, a Haswellben 8 pipeline port van, tehát olyan 800 darab utasítást kéne kiadni, ami nem memóriaművelet, hogy ne álljon üresben a proci. (Hardver szálakról beszélünk, szóval nincs context switch se, hogy "addig futtassunk mást") Van max 4x16 db regisztered, ami elég adatot kell tartalmazzon ehhez a 800 utasításhoz, amíg a LOCK INC fogja a memóriát. Hát, sok sikert.. Egy régi statisztika szerint valós x86 programban az utasítások kb. ötöde memória-operandussal dolgozik. Ja, és nem csak a LOCK INC-et kiadó processzorban történik mindez, hanem mindegyikben, amelyik a memóriához fordulna, miközben valaki LOCKolta a buszt.
ARM esetében ilyen nincs. Ott minden OoO, ha nincs függőség az utasítások között. A program helyes működése céljából itt ki kell adni a megfelelő acquire-release vagy barrier utasításokat, de ezzel csak a szinkronizációt lassítod, a szál "egyéb" utasításait, a thread_local / stacken levő adatokhoz hozzáférést nem.
[1]: Intel 64 and IA-32 Architectures Software Developer Manuals, 3.A. kötet
-
LordX
veterán
A 8.1.2 nem tudom hogy jön ide, a 8.1.1-et akartam hivatkozni arra, hogy egy load vagy store akkor atomi, ha befér egy cache line-ba, akkor is, ha nem MOV-ból jön, hanem bármilyen utasítás memory operandussal.
Ez egy fontos pont: "A locked instruction is guaranteed to lock only the area of memory defined by the destination operand, but may be interpreted by the system as a lock for a larger memory area."
Agner azt írja, hogy a LOCK utasítások (XCHG-t beleértve) erősen függ a memória sebességétől (ugyanaz a doksi, az első oldal alján a LOCK-ról egy bekezdés), amit bemásoltál, az a "Latency", amit ő úgy definiál, hogy "This is the delay that the instruction generates in a dependency chain. The numbers are minimum values. (.. blabla cache miss, floating point, exceptions ...) The latency listed does not include the memory operand where the operand is listed as register or memory (r/m). Tehát ebben nincs benne a cache és/vagy a memória hozzáférés által generált késleltetés, csak és kizárólag azt jelenti, hogy hány órajel után jöhet egy olyan új utasítás, ami erre az utasításra dependál, attól számítva, hogy a uOP issue megtörtént. Szóval az utasítás végrehajtásának idejének ez csak egy része.
Hogy hogyan van implementálva a LOCK, azt nem tudom, de egyrészt hardverről hardverre változik, másrészt igazából mindegy; az ordering miatt nem hajthatsz végre egy csomó memóriaműveletet amíg a LOCK be nem fejeződik: 8.2.2, bocs, de most eltekintek az egész fejezet bemásolásától Read-re van spekulatív végrehajtás (egyébként e miatt talán annyira nem dramatikus a pipeline stall), de más műveletet nem tud elkezdeni se a proci, és itt jön be az a pipeline bubble, amiről írtam.
[ Szerkesztve ]
-
LordX
veterán
Iiiiigen?
Mármint mi fogyott el Core 2-re, az unaligned 16/32/64 bites műveletek atomisága? Igen, de én ezt eddig meg se említettem, mert ma már irreleváns.
De már értem mi hiányzott, nem írtam le, hogy csak 64 bitig igaz a "atomi ha nem lép át cacheline-t" kitétel. Elnézést.
Új hozzászólás Aktív témák
- Milyen okostelefont vegyek?
- Politika
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- BestBuy topik
- Luck Dragon: Asszociációs játék. :)
- Suzuki topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Milyen cserélhető objektíves gépet?
- Milyen routert?
- További aktív témák...