2. Fórumok
  3. Processzorok, tuning
  4. Ez lenne az AMD gigantikus APU-ja?
Keresés

Új hozzászólás Aktív témák

  • #141 LordX veterán P.H. #140
    Új Válasz #141
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LordX

    veterán

    válasz P.H. #140 üzenetére

    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.

  • #139 LordX veterán P.H. #138
    Új Válasz #139
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LordX

    veterán

    válasz P.H. #138 üzenetére

    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.

  • #136 LordX veterán P.H. #135
    Új Válasz #136
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LordX

    veterán

    válasz P.H. #135 üzenetére

    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

Új hozzászólás Aktív témák