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

• #19 P.H. senior tag Abu85 #18

  Új Válasz 2012-10-02 12:21:12 #19

  Ú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

  

  P.H.

  senior tag

  válasz Abu85 #18 üzenetére

  Elképzelhető, hogy nem is teszi publikussá az Intel, hiszen más nem fog gyártani erre épülő megoldásokat. Persze ha a Larrabee New Instructions megegyezik a majdani 512 bites AVX-szel, akkor publikus lehet, de azt nem lehet tudni - egyelőre -, hogy az egyszerűsített utasításkészlet gépi kódolása megváltozott-e (a kihagyott MMX- és SSE-utasítások minimum 3-4 byte-osak, a CPU-s AVX-ek viszont 5-6 byte-nál kezdődnek; ezt az űrt hülyeség lenne kitöltetlenül hagyni).

  Ha nem gond, összeszedtem, amit a Xeon Phi-ról tudni lehet most, miben különbözik az x86-tól az új utasításokon kívül, és mi sejhető a jövőt tekintve.

  Az x86 valóban szigorú memória-sorrendiségi megkötést ír elő alapesetben, de Pentium 3 óta (SSE1) része az utasításszinten elérhető non-temporal store (nem-átmeneti tárolási) rendszer, amelynek révén a kiírt adat közvetlenül a memóriába kerül, nem jelenik meg a cache-ekben; így nem is kell értesíteni a többi magot sem a változásról, nem generál koherenciaforgalmat. Mára már minden adattípusra van ilyen utasítás: integer regiszterekre, 64, 128 és 256 bites vektorokra egyaránt, megvalósítva a weak memory ordering szemantikát (ami GPU-k vagy ARM CPU-k esetén a default).
  Pl. MOVNTPS
  A memóriavezérlők 64 byte-os adatszeletek mozgatására vannak kihegyezve (cache-line méret 64 byte), viszont ilyen adattípust nem ismer - jelenleg - az x86. Ezért 64 byte-os puffereket alkalmaznak ezekre az esetekre (2-8 db microarch-tól függően), amelyek a 4-32 byte-os kiírt mozaikelemekből összeállítják (összekombinálják = Write Combining) a 64 byte-ot és ezt küldik el a memóriavezérlőnek. Az eredeti memóriatartalomra csak akkor van szükség, ha az utasítások nem írják felül a mind a 64 byte-ot, ezt nyomon követik a pufferek és a nem módosított byte-ok helyére beolvassák az eredeti értéket, így kerül az a 64 byte a memóriavezérlőhöz.
  Hogy mire is jó ez:
  - ha ki kell nullázni egy több MB méretű adatterületet, akkor felesleges minden egyes írási műveletnél értesíteni a teljes rendszert, hogy módosítás történt; felesleges beolvasni is az eredeti memóriaértéket, úgyis felülírásra kerül; sőt felesleges a nullákat a cache-be írni, úgysem fér bele az összes.
  - memóriamásolásnál szintén szükségtelen a célterület eredeti tartalmát ismernie a CPU-nak, szükségtelen megjelennie a cache-ekben mind a régi, mind az új adatnak
  - ez az elv kiterjeszthető az egyes elemekkel végzett számításokra is
  Azt, hogy félig feltöltött célterületet másik mag ne kezeljen, ne olvasson bele, úgyis más módon - atomian kezelt jelzőkkel - célszerű megoldani.

  "All other memory types for stores that go through the write buffer (UC, WP, WT and WB) cannot be combined except when the WB memory type is over-ridden for streaming store instructions such as the MOVNTQ and MOVNTI instructions, etc. These instructions use the write buffers and will be write-combined in the same way as address spaces mapped by the MTTR registers and PAT extensions. When WCB is used for streaming store instructions, the buffers are subject to the same flushing events as write-combined address spaces."
  Processor_TechDocs/47414_15h_sw_opt_guide.pdf]Appendix A

  Más a helyzet, ha maguk a vektorregiszterek is 64 byte-osak, azaz 512 bitesek, mint a Xeon Phi esetében: ekkor a non-temporal kiírásuknál nincs szükség sem pufferekre, sem kombinálásra, a tartalmuk közvetlenül mehet a memóriavezérlőhöz. Csak akkor lenne szükség mozaikok összeállítására, ha a kiírt méret kisebb, mint 64 byte: a 64 bites MMX-, a 128 bites SSE- és a 256 bites AVX-vektorok esetén. Pontosan ezeket nem támogatja a Xeon Phi.

  64 byte-os vektorok esetén megváltozik a memóriaolvasás is, mivel ott alapesetben a kombinálás fordítottja történik: ha szükség van 1-32 byte-ra, akkor a CPU beolvassa a befoglaló 64 byte-os szeletet az L1D-be, majd onnan a regiszterbe a szükséges adatrészt. Ilyenkor ugyanúgy értesíteni kell a teljes rendszert, hogy ennek a magnak van egy másolata, hogyha valaki nem non-temporal módon módosítja, akkor tudjon róla. Ha viszont 64 byte-os egy regiszter, akkor be lehet vezetni weakly-ordered beolvasást jelentő utasítást is a meglevő mellé, így a beolvasott adat csak a regiszterbe kerül, a cache-be nem . Jól jön ez már akár memóriamásoláskor is, nem írja felül a forrásadat sem a cache-ek értékes tartalmát, főleg pedig olyan számításoknál, amikor egy-egy adatra csak egyszer van szükség.

  Ezáltal adott egy, az x86-szemantikához képest csekély koherenciaforgalmat nem generáló weakly-ordered memory model az 512 bites vektorokra.
  With a single instruction loading or storing more data, the processor has a better picture about the memory use of the application and does not have to try to piece together the information from the behavior of individual instructions. Furthermore, it becomes more useful to provide load or store instructions which do not affect the caches. With 16 byte wide loads of an SSE register in an x86 CPU, it is a bad idea to use uncached loads since later accesses to the same cache line have to load the data from memory again (in case of cache misses). If, on the other hand, the vector registers are wide enough to hold one or more cache lines, uncached loads or stores do not have negative impacts. It becomes more practical to perform operations on data sets which do not fit into the caches.
  8.4 Vector Operations

  A HSA dokumentációban olvasható, hogy ők is abban gondolkodnak, hogy a CPU-magok hajtják végre az OS-hívásokat, ez volt az eredeti Larrabee-koncepció is. Viszont nem igazán nevezhető "Latency-Optimized"-nek az a CPU-mag, amely a PCI Express busz túloldalán ül. Ezért az Intel a legegyszerűbb, egyben legpazarlóbb megoldást választotta: meghagyta a teljes x86-magokat az 512-bites végrehajtók körül, azaz épített egy 50-60 magos rendszert, amely önálló OS-t futtat. Ilyen már rég nem nagy feladat csinálni, 12 magon Opteronokból ez 4 foglalatot jelent; csak itt egy lapkára került a teljes rendszer. Ha felrajzoljuk az Opteron-rendszer ábráját, ugyanazt kapjuk, mint a Xeon Phi-nál:
  - minden mag saját cache-sel rendelkezik
  - a magok csoportokat alkotnak (Opteronnál egy-egy lapka), amelyeknek dedikált többcsatornás memóriavezérlőjük van
  - a csoportok rendelkeznek cache directory-val, Opteronnál HT-Assist néven ismert, az L3-ból vesz le 1-2 MB-ot
  - a csoportok nagy sebességű busszal vannak összekötve (~HT)

  Ha ezt a rendszert beköltöztetik a CPU mellé, akkor lehántható a felesleges teljes értékű x86-CPU mag az 512-bites végrehajtókról, hiszen az OS ott fut a szomszédban a post-Haswell magokon, elérni őket nem idő. Marad tehát egy maréknyi 512-bites vektorvégrehajtó saját utasításkészlettel, fejenként körítve utasításkezeléssel, skalár integer/FP egységgel és némi cache-sel. Mivel a vektorműveletek többnyire megkerülik a cache-t, ezért azok csak néhány kisebb feladata lesznek jók:
  - konstansok, táblázatok tárolására, melyeknek nincs hely regiszterben (read only cache)
  - skalár feladatok tárhelyének, ideiglenes adatok változóinak (read-write L1)
  - atomi, szinkronizációs és megosztási feladatok ellátására (data share)
  Ez így pedig már eléggé emlékeztet valamire...

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