Valahogy eros ketsegeim vannak...

miért jutott eszembe a cikk olvasása közben, hogy java?

"Miért imádják az aranyat? Nem lehet megenni..."

Van párhuzam, csak ez más (alacsonyabb) szinten mozog és teljesen más a célja (hatékonyság, skálázás, vs. legnagyobb közös osztó, hogy minden platformon lehessen futtatni).

Fotóim és kalandjaim a világ körül: https://www.facebook.com/fmartinphoto/

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

Ez nem olyan koncepció, mint a programozható utasításkészletű processzor (VIA, vagy Cyrix nem emlékszem - megbukott)? És mintha hasonlítana az IBM Cell, Intel MIC elgondolásra is. Mi itt az újdonság? (elnézést, nem olvastam el szóról-szóra a cikket).

Nekem is pont ez jutott eszembe, vagyis nem jutott eszembe mi is volt a neve a hogyishívjáknak, annak a procinak, amelyiknek frissíthető volt az utasításkészlete...

Eladó dolgaim: Marbo Sport MH-W105

Transmeta Crusoe volt az.

[ Szerkesztve ]

A Soft Machines azt hiszi, hogy feltalálta a spanyol viaszt, csakhogy (BREAKING NEWS!!!) nem.

Gyakorlatilag csináltak egy olyan procit, ami dinamikusan osztja el az erőforrásait és ez akkora hír?!

"...A VISC architektúra teljes reformot kínál a mai rendszerekhez képest, ami minden procikáján látszik...." Ezen besírtam...

Galilei halott! Már Einstein sem él! ...és én is nagyon szarul érzem magam...

Úgy van! Épp most találtam meg én is, hosszas keresésekkel. Cavington rulz!

Eladó dolgaim: Marbo Sport MH-W105

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

A kicsire nem adunk... a nagyot meg leszarjuk!

Így elsőre jól hangzik. Viszont kíváncsi vagyok, ki és mikor fogja implementálni. Intel-t egyből kihagyom .

Ám mivel az AMD támogatja, ezért valszeg implementálni fogja. Ha bevállik, akkor tippre ARM gyártók, talám még az Imagination is az MIPS-el fog rá építeni.

"Ezért lovagol a pokolba a konzumer IT piac. A hülye igények... . Azt sem tudod, hogy mit akarsz de az jöjjon havonta frissités formájában."

Én nem tudom eldönteni, hogy ez szándékos-e.

Jol ertem, hogy az a mondas, hogy 1 milliard tranyobol gyorsabb, mint egy 300 millio tranyos haswell mag, ami 1 ghz-en megy, de csak 50%-kal? Hat tekintve, hogy a haswell 3-4 ghz-en tud menni, ez azert nem egy nagy mondas.

Hmmm...
Mohammad Abdallah az egyik alapító, az egyik támogató a Mubadala, a cikket pedig egy Abu85 nicknevű házigazda írta... Gondolom ha eljutnak a gyártásig, kizárólag a GloFo gyárthatja...
Amúgy elméletben jól hangzik az elképzelés. Elméletben...

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

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.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

A 300 millioban is benne van az uncore. 8 magos xeon osszesen 2.6 milliard tranyo, mindennel egyutt.

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.

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.

A cikk fénypontja: Érthetőbben fogalmazva itt arról van szó, hogy jórészt a manuális szinkronizációtól függ, hogy az adott algoritmus szálszintű párhuzamosítása meddig skálázódik.

evDirect villanyautós töltőhálózat

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.

Utoljára a bullshit generátor dobott ilyesmiket, hogy aszondja: "Optimatizáljuk az informatikai BackOffice-t"...

QNX is cool!

Na vegre valaki jol latja a problemat.

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. /

Don't sing if you want to live long, they have no use for your song, you're dead, you're dead, you're dead, you're dead and outta this world.

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 melegvi az autoparallelizer-t. Minden modern C++ fordító, sőt talán a Java és .NET runtime is tudja.

a-ha...
/most akkor nagyon értelmesen nézek, mintha tudnám, hogy miről van szó. /

[ Szerkesztve ]

Don't sing if you want to live long, they have no use for your song, you're dead, you're dead, you're dead, you're dead and outta this world.

Olvasd el tanenbaum szar könyvét, alapozáshoz jó. utána nekifuthatsz hennessey computer architecture könyvének is (ez már azért súlyos).

Én ezt ajánlom: https://www.coursera.org/course/comparch (ez is súlyos tud lenni)

Nekem tetszik, jól hangzik! Csak a sorozatgyártásig még kell "kicsit" várni.

oraihunter felhasználónak 381 pozitív és 0 negatív értékelése van a fórumon! Ha sürgős, akkor az adatlapon a telószám (06-30-293-42-53), de számkijelzés nélküli hívást már 21-éve nem fogadunk!

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

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.

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.

Mikorra várható, hogy ebből piaci termék lesz, ha lesz egyáltalán?

Minden számítógép füsttel működik, ha kimegy belőle, akkor nem működik.

+1

Ká Úr

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.

Ez egy Transmeta klónnak tűnik, amivel nincs semmi baj, mert jó elgondolás volt, csak rossz időben jött.

Tök érdekes nézni, ahogy gyakorlatilag újra feltalálják az Itaniumot.

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

Nagyon, de nagyon különbözik az Itanium architektúrája ettől, bármilyen kevés is az információ.

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

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.

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.

Ennyit a 6-8 magos INTELekről ez a jövő meg a kvantum processzor

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