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

• #53 P.H. senior tag LordX #47

  Új Válasz 2014-10-31 18:46:18 #53

  Ú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 LordX #47 üzenetére

  (#46) lenox
  (#47) LordX

  Kissé elbeszélünk egymás mellett, ennek oka egyrészt a megközelítés iránya (microarchitekturális vagy architekturális/ISA felőli) illetve az, hogy a cikk/forradalom több - konkétan 3 - szemszöget kever.

  Az első "forradalomra", a SIMT szemléletre és a threadlet/bundle párhuzamra nézve hoztam példaként az Itaniumot, ami abszolút architekturális/ISA kérdés: nem a kicsinyes "melyik volt előbb" miatt, hanem hogy lehetett-e tanulni annak hibáiból mára. Az Itaniumba az Intel és a HP anno belepakolt mindent, ami az akkori - még nem GPU-releváns - (és akár mostani) CPU-tervezési szemszögből megvalósítható és hasznos: a cikkben említett "hardveres szálaktól" kezdve a tranzakcionális memóriakezelés előfutárának tekinthető spekulatív végrehajtáson át az event-based multithreading-ig (amire az AMD is azt promózta, hogy annyira nem is rossz). Olyannyira bíztak ebben a technológiai virgázásban, hogy némi "high-endségi időszak" után asztalon képzelték el. Csak sok volt ez egyszerre.
  Ez a felépítés nagyban épített a programozókra, mivel a programozók tudják igazán - és némi forráskódi megjelölés használatával jelzik a fordító számára -, hogy mit is akarnak a programban az adott helyen, ne kelljen ezt a hardvernek kitalálni; és ez így is lenne valójában jól, ha a programozókra mint mérnökökre tekintünk (ilyen áthallása viszont van a cikknek is). Nyilván legalábbis ezekhez a megjelölésekhez vagy kissé bővíteni kellett a programnyelvek eszköz- és keywordkészletét, vagy okosabbá kellett tenni a fordítóprogramokat; és itt el is halt az egész: kialakult az a kép, hogy az Itanium egy nehezen programozható böszme nagy dolog, ami az elvárt teljesítményt nem hozza. Persze nyári konyhát kevesebb eszközzel lehet építeni, mint felhőkarcolót, nem véletlenül van nyári konyhából több a világon, mint toronyházból, pedig annak minden mutatója (helykihasználás, energiahatékonyság, komfort) sokkal jobb.

  A második "forradalom", és ez már microarch-kérdéskör, az egymag=kétmag kérdése lenne, ami mondjuk a fenti SIMT megközelítésnek pont mindegy, ott csak az számít, hogy hány hardveres szál futtatható egyszerre az adott végrehajtóegység-készleten (GCN-en 16, Itaniumon attól függ, hány (max. 128-32) integer regisztert és (max. 128-32) FP-regisztert használ a ciklus 1-1 iterációja, ezt adott init-utasítással - 16-os egységekben - kell jelezni az adott ciklus előtt), ez a tradicionális szotfveres szálaknak, és az OS-nek fontos. Ehhez hozzá illik (illene) tenni, hogy a konkurencia sem pihen: ha az 1=2 mag forradalom, akkor az 1=8 mag rendszerváltás? Ez nyilvánvaló válasz a tucatnyi in-order magot tartalmazó, kiemelkedő magszintű teljesítményt nem kívánó microserverek iránti igényre, ráilleszthető bármely mai Intel64-magra, kellemesen részletes leírással.

  A harmadik forradalmi újdonság megintcsak architekturális: a fizikai, rejtett, cserélhető utasításkészlet feletti valós ISA. Ez nagyszerű, jobban belegondolva így működik mindegyik IA-32 és x64 CPU a kb. Pentium Pro óta, és az Itanium x86->IA-64 fordítása is (amely először hardveres volt, aztán opcionális szoftveres réteg lett). A belső utasításkészlet vajmi keveset változott 20 év alatt (sőt, néha kellemetlenül keveset), a programfuttatási kompatibilitást adó ISA pedig az x86/x64 esetén inkrementálisan fejlődött. Egyféle értelmezésben ez toldozás-foltozás, másikban pedig ez piaci igény (ar ARMv7->ARMv8 kompatibilitás módja sem véletlen).
  Csak hogy megemlítsük az elmúlt 20 év két legnagyobb összértékben értékesített ISA-ját: ha ez érinti is az x64-et (azaz az AMD feladja a sokszor továbbfejlesztett RISC86 belső utasításkészletet), az Intel-t ez biztosan nem; az ARM-vízió lehetséges, HA vannak előnyei és nagyobbak, mint a hátrányai:
  - pl. nem előnye, hogy pont olyan decode-réteget kapna, amiért az x64-et sokan szidják és energiahatékonységét kritizálják
  - a belső SIMT kihasználásához az ARM ISA-nak is kellene kapni egy SIMT-kiegészítést, amit aztán használnia kellene a compilereknek és végső soron a programozóknak
  - a Jazelle példája sem kecsegtető

  Remélem, ebből nem úgy tűnik, hogy "majd én megmondom a frankót", viszont egyrészt ami sok elemében előrelépésnek tűnik, az egyszerre sok lehet, másrészt nem hiszem, hogy jó elvárás a CPU-forradalomba GPU-megoldásokat látni. SZVSZ ha a CPU-ra úgy tekintünk mint a (low latency) közúti közlekedésre, ami mindenki (~minden programozó számára) könnyen elérhető és gyors autóval gyorsabban érjük el a célt, és a GPU/SIMT-re úgy, mint egy normálisabb vasúti közlekedésre, ami tömegében olcsóbb, és szinte minden szempontból jobb kihasználtsági/fogyasztási/sebességi mutatókkal rendelkezik, viszont tényleg mérnökök kellenek az üzemeltetéséhez és nem háztól-házig megoldás, akkor könnyebb megérteni, hogy miért nem lehetne teljesen elkeverni a kettőt, csak egy öszvért alkotni, ami a közlekedési analógiában egy (kis)busz lenne. Forradalom címen.

  [ Szerkesztve ]

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

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