Új hozzászólás Aktív témák
-
P.H.
senior tag
Mi az Itanium?
- sok-sok execution unit egybepakolva, ~in-order front-tal
- adott (fordító)programra bízottan az egymást követő, egymástól független utasítások egy egységbe csoportosítottak, ezek garantáltan futtathatók egyszerre a sok-sok execution unit-on; ezek a csoportok változó hosszúságúak: ~VLIW ugyan, de leginkább Variable Length Instruction Word-ként jellemezhető.
- "SIMT" végrehajtás kezdeményezhető az arra alkalmas ciklusokra gépikód-szinten, dedikált utasításokkal (csak ezeket a ciklusokat akkor meg kellett jelölni speciálisan forrásnyelvi szinten; érdekes...):
"Modulo scheduling of a loop is analogous to hardware pipelining of a functional unit since the next iteration of the loop starts before the previous iteration has finished. The iteration is split into stages similar to the stages of an execution pipeline. Modulo scheduling allows the compiler to execute loop iterations in parallel rather than sequentially. The concurrent execution of multiple iterations traditionally requires unrolling of the loop and software renaming of registers. The Itanium architecture allows the renaming of registers which provide every iteration with its own set of registers, avoiding the need for unrolling. This kind of register renaming is called register rotation. The result is that software pipelining can be applied to a much wider variety of loops – both small as well as large with significantly reduced overhead."
"Register rotation, predication, and the software pipelined loop branches allow the generation of compact, yet highly parallel code. Speculation can further increase loop performance by removing dependency barriers that limit the throughput of software pipelined loops. Register rotation removes the requirement that kernel loops be unrolled to allow software renaming of the registers. However in some cases performance can be increased by unrolling the source loop prior to software pipelining, or by generating explicit prolog and/or epilog blocks.""During the prolog phase, a new loop iteration is started every II cycles (every cycle for the above example) to fill the pipeline. During the first cycle of the prolog, stage 1 of the first iteration executes. During the second cycle, stage 1 of the second iteration and stage 2 of the first iteration execute, etc. By the start of the kernel phase, the pipeline is full. Stage 1 of the fourth iteration, stage 2 of the third iteration, stage 3 of the second iteration, and stage 4 of the first iteration execute. During the kernel phase, a new loop iteration is started, and another is completed every II cycles. During the epilog phase, no new iterations are started, but the iterations already in progress are completed, draining the pipeline. In the above example, iterations 3-5 are completed during the
epilog phase."- mindez Event-Based MultiThreading-gel ellátva (ha egy szál futását pl. RAM-hozzáférés, szinkronizációs változóra várakozás, ... egyéb nagy késleltetésű esemény akadályozza, vált másikra)
Lássuk a különbségeket!
Amúgy a "Harmadik amit nem ertek, hogy oke, hogy 350 mhz-en valahogy tudjak adattal etetni, de ez kb. sehogy sem fog skalazodni az orajellel." teljesen igaz, az Itanium is meg volt/van fejelve a saját korában extrém méretűnek számító last-level cache-ekkel, igaz, ott a szoftveres spekulatív betöltés és végrehajtás is közrejátszott.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
(#46) lenox
(#47) LordXKissé 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
ph A VISC architektúra teljes reformot kínál a mai rendszerekhez képest.
- Milyen TV-t vegyek?
- Politika
- Milyen alaplapot vegyek?
- Bluetooth hangszórók
- sziku69: Szólánc.
- Kerékpárosok, bringások ide!
- Otthoni hálózat és internet megosztás
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Vezetékes FEJhallgatók
- További aktív témák...
- Beszámítás! Intel Core i7 7700 4mag 8szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 8700K 6mag 12szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 9700K 8mag 8szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 9700F 8mag 8szál processzor garanciával hibátlan működéssel
- Intel Core i9-13900K
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen