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

• #26 LordX veterán

  Új Válasz 2014-10-27 21:29:41 #26

  Ú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

  

  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.

• #30 LordX veterán sz.balazs.95 #29

  Új Válasz 2014-10-27 21:51:45 #30

  Ú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

  

  LordX

  veterán

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

  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.

• #33 LordX veterán JColee #32

  Új Válasz 2014-10-27 22:59:44 #33

  Ú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

  

  LordX

  veterán

  válasz JColee #32 üzenetére

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

• #37 LordX veterán namaste #36

  Új Válasz 2014-10-28 00:35:20 #37

  Ú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

  

  LordX

  veterán

  válasz namaste #36 üzenetére

  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.

• #41 LordX veterán lenox #38

  Új Válasz 2014-10-28 10:24:58 #41

  Ú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

  

  LordX

  veterán

  válasz lenox #38 üzenetére

  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.

• #44 LordX veterán P.H. #43

  Új Válasz 2014-10-28 20:23:33 #44

  Ú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

  

  LordX

  veterán

  válasz P.H. #43 üzenetére

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

• #47 LordX veterán P.H. #45

  Új Válasz 2014-10-29 13:56:18 #47

  Ú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

  

  LordX

  veterán

  válasz P.H. #45 üzenetére

  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.

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