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

  • davidsone

    addikt

    válasz sz.balazs.95 #50 üzenetére

    :DDD az lett volna a másik, csak nem akartam itt okoskodni :)

    ...reklámozzák, terjesztik, beszippantják az agyadat, megerjesztik...

  • 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 ˙˙˙

  • Petykemano

    veterán

    Ezzel az ötlettel mi a helyzet, látjuk majd valamikor valahol implementálva?

    Találgatunk, aztán majd úgyis kiderül..

  • Supra

    tag

    Hát, én igyekeztem végigolvasni a cikket, meg a hozzászólásokat is:
    Értem, hogy mi ennek az előnye, de azt teljes homály fedi, mitől lenne ez gyorsabb?!?! Ez röviden akkor is csak egy risc magokkal telepakolt CPU...
    Ennek is van egy saját, ideális programozási módja - de ugye a "hagyományos" CPU is marha nagyot gyorsul, ha egy adott platformra írom át. Ha egy konkrét tipusú CPU-ra, még gyorsabb. Az, pedig, hogy minden piaci résztvevő eldob mindent (intel,AMD,ARM, apple) és mind erre a platformra áll átt, az barátilag is utópia.

    Szerintem itt lényegében azt próbálják HW alapon megcsinálni, amit a fordítók próbálnak software-esen: bár azt nem értem, hogy a változó, legalacsonyabb szintű kódot mi a fene állítja elő?

    De a fentieket félretéve, a legfontosabb problémát ez nem oldja meg: A mai programok 90%-a még mindig egyetlen szerencsétlen programszálon fut - és ahogy a cikk is írta, ezt a fenti rednszer sem szereti. Innentől kezdve ez egy vihar a biliben.

    Szerintem előbb érjük el a fizikai határt, TANULJUNK MEG PROGRAMOZNI, aztán majd meglátjuk, merre tovább, vannak más lehetőségek is. Annyi pénzt beleölni ebbe, amiből egy kissebb országot meg lehetne venni, kicsit túlzásnak érzek.

    CSillagkapu rajongók ide -> www.SG-1.hu

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