Új hozzászólás Aktív témák
-
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.
-
#54
Petykemano
veterán
Petykemano
veterán
Ezzel az ötlettel mi a helyzet, látjuk majd valamikor valahol implementálva?
-
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.
-
LordX
veterán
A hasonlóság kb. kimerül abban, hogy sok darab végrehajtóegység van mindkettőben, és hogy a 256 bites utasításokat 256 bites egység számolja, van predikció
Haswell:
- frontendje: fetch -> predecode -> instruction buffer -> decode -> uOp buffer -> uOp decode -> schedule -> issue
- Out-of-order végrehajtás, hardveres utasítás ütemezés és exec port választás
- Több ciklus utasításait automatikusan hajt végre párhuzamosan, ha nincs függőség.
- Automata register renaming ha nincs dependencia, minden in-flight utasításhoz.Itanium:
- frontendje: fetch -> decode -> issue.
- In-order végrehajtás, szoftveres ütemezés és port választás.
- ciklusokat szoftveresen kell unrollolni, prolog-iteration-epilog fázisokat kell a fordítónak generálnia.
- Register renaming csak taggelt ciklusoknál.A szuperscalar hardverből csinál mindent. VLIW-nél a fordítóprogram csinálja a frontend majdnem minden feladatát (a felszabaduló power/tranzisztor/stb. budgetet meg órajelre/végrehajtóegységekre/cachere/stb. lehet fordítani).
A cikkben írt cucc továbbra is superscalar "physical core"-okat használ.
-
lenox
veterán
Nyilvan van hasonlosag, de az egyetlen lenyeges ujitas itt az, hogy a virtualis magokhoz igeny szerint lehet egy vagy tobb fizikai magot rendelni. Tehat elvileg a fizikai magokat nagyobb hatasfokkal lehet hasznalni, mivel ha egy adott virtualis maghoz nem kell, akkor at lehet rakni masikhoz. Eddigi megoldasoknal meg ha a mag valamilyen eroforrasa nem volt kihasznalva, akkor malmozott. De pl. pont ezert egyertelmu, hogy ez nem lesz egy threaden teljesitmenybajnok, hiszen ha egy magban eleve van annyi eroforras, mint amennyit a SM egy virtualis maghoz tud rendelni, akkor nincs semmi elony.
-
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.
-
LordX
veterán
Ezt írták is a PDF-ben, az alacsony órajel erősen felfelé torzítja a mért IPC-t. A használt fizikai magok most direkt egyszerű magok voltak, hogy tudjanak koncentrálni a globális frontendre. De nem is 2x IPC-t mértek, hanem 1,5-7x-et (3x-es átlaggal)..
Én is a hiszem ha látom állapotban vagyok, de legalább nem teljes a sötétség.
-
lenox
veterán
Tovabbra sem ertem, hogy ebbol hogy lesz nagyobb ipc. Ez amit irsz pont inkabb kisebb ipc-t, de nagyobb elerheto clockot kene jelentsen, nem?
Amugy en azt sem ertem, hogy ha 2.1 az ipc 350 mhz-en vs 1.39 az ipc 1 ghz-en (haswell), ebbol en azt szamolom, hogy a haswell kb. 2-szer gyorsabb.
Harmadik amit nem ertek, hogy oke, hogy 350 mhz-en valahogy tudjak adattal etetni, de ez kb. sehogy sem fog skalazodni az orajellel. Szoval ebbol nagy teljesitmeny sehogy sem lesz. Meg az esetleg lehetseges, hogy valamilyen kis teljesitmenyt esetleg kisebb fogyasztassal lehet kihozni. -
LordX
veterán
Na ez már valami: A 2-magos processzornál majdnem egy 2-bypass-clusterrel rendelkező szuperskalár processzor standard leírása található. Annyi akkor az ötlet, hogy okosabban osztják szét a clusterek (az ő terminológiájukban: physical core) között az utasításokat; eddig az első lehetséges portra (és ezáltal clusterbe) osztotta a dispatch.
Gyakorlatilag csinálnak egy sok exec portos processzort, de a bonyolult bypass és kontroll vezetékezést kettévágják (physical core-on belül minden marad; ezért mondom, hogy ugyanaz, mint egy bypass cluster), cserébe +3 clock az új pipeline stage (a threadlet formálás). Kicsit szkeptikus vagyok, de akár.
A szoftver meg teljesen mellékes, csak arra való, hogy ARM->VISC utasításkészlet konverziót csináljon, a la Transmeta. A koncepció ugyanúgy életképesnek látszik nélküle.
-
namaste
tag
A cikkben nem szerepel a lényeg, hogyan hajt végre egy szálat több magon.
A programszál egymástól függő utasításait csoportosítja (threadlet) és ezeket a részeket a fizikai processzormagokon párhuzamosan végrehajtja. Ha a szál darabok mégsem lennének függetlenek egymástól, akkor a magok hozzáférhetnek egymás regisztereihez. pdf
-
#35
ivana
Ármester
Kotomicuki
#19
válasz
Kotomicuki
#19
üzenetére
Ez értelmetlen hülyeség és szembemegy minden logikával. Az absztrakciós rétegek kellenek mert egyébként még a legjobbak is elvesznek, hogy épp mi van, mi történik. Nem beszélve biztonsági illetve bug javításokról.
-
#34
oraihunter
aktív tag
oraihunter
aktív tag
Nekem tetszik, jól hangzik!
Csak a sorozatgyártásig még kell "kicsit" várni. 
-
LordX
veterán
Ha ez lenne, még meg tudnám érteni, de abból nem jön ki a jobb IPC. Abból pontosan ugyanakkora IPC jön ki, mint eddig, csak ügyesebben osztják szét ugyanazt a teljesítményt több szál között. (A HTT pontosan ezt csinálja 2 szál között!)
Viszont pár anyagon látszik, hogy van 2 db "fizikai" mag legalul, és a "heavy thread" mindkét magra van szétosztva. (Grafikonokon 4 fizikai magos változat is van.) Ha ezt a szoftveres middleware csinálja, akkor újra feltalálták
a melegviaz autoparallelizer-t. Minden modern C++ fordító, sőt talán a Java és .NET runtime is tudja. -
Jól értem, hogy itt arról van szó, hogy nem x db fizikailag elkülönített procimag van, hanem van 1 nagy, ami az adott programhoz igazodik; pl. 1 nagyobb és 3 kisebb magra „oszlik fel” az egy fizikai mag teljesítménye, ha az adott programhoz az az ideális, de ha egy program csak egy szálon fut, akkor meg az egész 1 magként viselkedik?
/tényleg nem tudom, azért kérdezem.
/ -
LordX
veterán
Az a baj, hogy _semmi_ nincs az ötletből leírva.
Az első blikkre HyperThreading on steroids.
Második blikkre valami mágikus ILP exploitolás. Ami gyanúsan FUD, mert azért kezdtek el többmagos processzorokat gyártani évekkel ezelőtt, mert már gyakorlatilag lehetetlenné vált ezt hatékonyan növelni. Ilyen 5%-okat sikerül az előző generációkra rakni évente olyan overkill megoldásokkal, hogy ~70 elemes ROB, meg 12 wide issue, ami exponenciálisan növeli a bypass utak számát, és/vagy a kontrol logika méretét. Gyakorlatilag a fél programot elkezdi a processzor spekulatívan előre feldolgozni, hogy találjon olyan utasítást, ami független a jelenleg in-flight számolásoktól, hogy még egy kis IPC növekedést eredményezzen.Szóval valami kis rövid technikai leírást arról, hogy milyen kalapból húzták elő azt a 2x IPC-t, úgy, hogy még egy szoftveres rétegnek is lett hely mellette, mert ez csak befektetővakító marketinganyag.
-
lenox
veterán
Hat pedig ha ertesz valamennyit hozza, akkor nezd meg a ceg oldalan a pdfeket. 350 mhz-en rovid pipeline-nal nagy ipc? Gratula, de az lofasz. Ne hasznaljunk intel compilert, mert esetleg valamit tul gyorsra forditana. Stb, stb. Ez ebben a formaban tul sokat nem er, de befektetot esetleg lehet meg fogni. Licenszelni nagyon nincs mit belole, szerintem az amd-nek es az intelnek is van 20 otlete, amit hamarabb valositanak meg, mielott innen licenszelnenek.
-
smkb
őstag
Erről a cégről süt, hogy nem más, mint alibikutatásfejlesztésinnovációval dollármilliók kilapátolása, a támogató cégek számlájáról. Sok hasonlóra láttunk már példát.Persze sosem lesz majd belőle semmi érdemlegesen használható, ami nem gond, mert úgyis csak a beletolt pénz újraelosztása a lényeg.
-
#19
Kotomicuki
senior tag
Kotomicuki
senior tag
Ezt vmi hasonlóan lehetne a mostani architektúrákra átültetni, mint az otthoni számítógépek hőskorában: a gépben, hardveresen tárolva/integrálva az op.rendszert (is) -> a mostani gyártástechnológiával: bele a központi egységbe... (nem, nem vindózra, vagy ahhoz hasonlatosan gyalázatos módon megírtra gondoltam, mint op.rendszer - pl. a rosszindulatot eleve ki kell rekeszteni a lehetőségek közül, nincs tolerancia és keveredés: adott program csak a neki kiosztott adatokkal dolgozhat és nem turkálhat a máséban, pláne nem: programkódban).
Ugyan, ehhez össze kéne hozni pár, szoftverben ászt és pár, hardveres téren fenomént, de némi pénzzel ez is megoldható lenne... -
Abu85
HÁZIGAZDA
Nem érted jól. Az 1 milliárd tranyó 80%-a uncore, azért demonstrálták így, hogy lássák van rá építve egy komplett SoC.
A fejlesztők azt mondják inkább, hogy fal felé tartunk, és a jelenlegi potenciális megoldások nagy része arra jó, hogy lefejeljük a falat. Ez a probléma. Minden másra van valami jó megoldás, de az alapokon változtatni kell.
(#16) Egon: Igen sok az Arab.
A TSMC-nél kezdték, de nyilván a GloFo sem akadály. Annyira ez a Soft Machines számára nem lényeges. Tekintve, hogy a licenc biztosítása a cél, így minden bérgyártóval kell a kapcsolat. -
Hogyan viszonyul a fenti elképzelés egy teljesítmény orientált jelenlegi AMD vagy Intel processzorhoz képest?
Ha jól értem lesz egy közös virtuális architektúra, ami alatt a hardver cserélhető tetszés szerint. A kompatibilitást a szoftveres réteg fogja biztosítani ( mármint a köztes fordító ). A plusz egy réteg miatt lesz egy bizonyos késleltetése a dolognak... érdekes. Kíváncsi vagyok, lennék a nagy cpu gyártók véleményére
-
#5
Peter Kiss
őstag
Peter Kiss
őstag
Teljesen ésszerűnek hangzik, és igazság van benne bőven. Mindig kiröhögöm azokat, akik ész nélkül irkálnak olyan programokat, amelyek végtelen szálon dolgoznak, mert az atomgyors lesz. facepalm
-
#4
antikomcsi
veterán
antikomcsi
veterán
Ha tőlem kérnének erre támogatást, akkor egy ruppót nem adnék nekik, még ha meg is tehetném amúgy.
az lett volna a másik, csak nem akartam itt okoskodni 
Csak a sorozatgyártásig még kell "kicsit" várni. 
/
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Gondolom ha eljutnak a gyártásig, kizárólag a GloFo gyárthatja... 
Új hozzászólás Aktív témák
- Bomba ár! Dell Latitude 5401 - i5-9400H I 8GB I 256SSD I 14" FHD I HDMI I Cam I W11 I Gari!
- Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
- Telefon felvásárlás!! Honor 400 Lite, Honor 400, Honor 400 Pro
- 137 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4080
- Vállalom Xianomi Okos kamerák, szoftveres javíttását
Állásajánlatok
Cég: FOTC
Város: Budapest