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

• #611 7600GT senior tag Raymond #610

  Új Válasz 2007-05-16 20:36:53 #611

  Ú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

  

  7600GT

  senior tag

  válasz Raymond #610 üzenetére

  Ha tudsz angolul akkor egy naon minimálisan leírnád nekem h mit ír?
  Köcike

  Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.

• #617 dezz nagyúr Raymond #610

  Új Válasz 2007-05-16 23:38:57 #617

  Ú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

  

  dezz

  nagyúr

  válasz Raymond #610 üzenetére

  Hmm, Core2 esetén fel van tüntetve egy bizonyos Internal Results Bus, a K10 esetén az ilyesmi hiányzik az ábrákról.
  A végkövetkeztetésekben meg egy szó sem esik a natív 4-magosság mellett a másik legfontosabb változás, a kiemelkedő floating-point (SIMD) teljesítmény mind desktop, mind munkaállomás, mind szerver vonalon jelentette előnyről.
  
  (#611) 7600GT: nemrég még ''lázadtál'' a technikai szöveg ellen, most meg egyenesen igényedet fejezed ki? Bár nem tudom, vállalkozik-e Raymond egy 10 oldalas, tömény technikai szöveg pár mondatba sűrítésére.

• #630 P.H. senior tag Raymond #610

  Új Válasz 2007-05-17 20:54:47 #630

  Ú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

  

  P.H.

  senior tag

  válasz Raymond #610 üzenetére

  Nagyon jó cikk, minimális háttérismeretek birtokában érthető (= ha tudja az ember, hogy miről beszél, akkor tudja azt is, hogy mit mond). Egy kicsit zavaró, hogy micro-opokban fogalmaz macro-opok helyett.
  
  dezz #617: K10 esetében is van result bus (írja is, hogy nem ábrázolja, mert túl bonyolult lenne az ábra tőle), result bus nélkül az egész működésképtelen lenne (INT oldalon nincs is register-rename, csak resultbus->ROB/ICU forwarding, legalább K7 óta).
  
  dezz #619: Sajnos az Intel visszatért a PPRO/P2/P3 complex-simple-simple... (itt most még egy -simple, 4-1-1-1 micro-op) decoder felállásához. Valahogy mindig RISC-felfogású decoder-eket akarnak tenni egy x86 elejére P6 óta (Netburst alatt az egyszem decoder szűkösségét elnyomta a trace-cache), pedig pont oda kellene CISC-felfogás. Ezek szerint három egymást követő OP reg,mem típusú utasítást Core2 3, K10 1, (de még ha nem DirectPath Double útra mennének, akkor is) legrosszabb esetben 2 órajel alatt fordítaná. Itt is van egy szűk keresztmetszete, illetve a mem tagokat Core2 1/órajel (cache lehet, hogy dual-ported, de LOAD - port2- csak egy van), K10 2/órajel szélességben hozza fel Data Cache-ből legjobb esetben, akár 2x128 bitet.
  
  akosf #619: üresben ugyan nem járnak, de nem biztos, hogy FP munkát végeznek, lévén shared INT/FPU pipe-ok (számláló, forrás- és célcímek kezelése, branch futtatása, stb...)
  Pont a macro-op cache-t említettem korábban is, a fetch/decode itt majd' a pipe felét viszi el, nem csak 2-3 órajelet/stage-t. A másik ötletem, a Hyper-Threading azért játszhatna itt, mert mostmár teljesen tiszta, hogy a pack-stage-ek után nincs vízszintes mozgás a macro-ophármasokban, minden utasítás arra a portra megy, amelyik lane-en van, főleg FPU-ban teli van gap-ekkel. Ezeket tölthetné meg másik szál, INT esetén pedig az 3 micro-op/cycle miatt nem nehezedne nagyobb nyomás (INT-ben sokkal nagyobb gondot okoznak a függőségek, mint a szélesség). A branch-ágak práhuzamos futtatása sajnos nem, megintcsak amiatt, mert nincs INT oldalon register-rename.
  
  dezz #622: 3+2+2+2-t nem tudok kiolvasni az Optimization Guide-ból, csak 3/2+2+2-t. Mivel végig 3-széles maradt a micro-architecture (3 macro-op/sor), szerintem nincs 4 decoder, a VectorPath csak ábrázolásszinten külön oszlop (vagy a 3 DirectPath, vagy VectorPath).
  
  akosf #623: érdekes módon az FSTORE-t az idők folyamán átnevezték FMISC-re. Mindenesetre ennek van belső ROM-táblája a betölthető konstansokhoz, ez kezeli az INT->FP és FP->INT konverziókat (fild, fist(p)), és ahogy mondod, az FSIN, FCOS, ... utasítások által generált spec. micro-opokat futtatja (lehet, hogy csak ez fér hozzá a belső, programozói szinten nem látható átmeneti (scratchpad) register-ekhez?)
  IPC: majdnem mondtam, hogy próbálj egy átlapolt, nem függő FPU/INT utasítássort, de azt meg a decode limitálja 3-ra.
  
  dezz #624: azért majd meglátjuk, 65 nm-en meddig fogják felvinni az órajelet, mennyi tartalék van benne.
  
  akosf #625: felfüggesztődik? Nem hiszem el...
  SMC: egy (a? ) másik topikban zajló események miatt pár napja multi-core/multi-processor/NUMA témába ástam bele magam. SMC természetesen lehetséges (még mindig 8086 miatt, de már nem sokáig lesz ez így), AMD-nél a MOESI-szerinti cache-probe módosítás esetén kiüríti az I-cache adott vonalát (store-jellegű probe esetén az I-cache-t is ellenőrzi system-wide), és érvényteleníti a teljes CPU-pipe-ot. Ha jól emlékszem, Netburst alatt nyomta ki a teljes instruction cache-t egy SMC.
  
  dezz #628: DirectPath-on mennek egy 1 micro-opos utasítások (3 micro-op/órajel), DirectPath Double-re a 2 micro-oposok (1.5 micro-op/órajel, lényegében ugyanaz, mint a DirectPath Single, csak 2 órajel alatt fordít), VectorPath-ra a többi. Csak ennyi a szabály.
  
  akosf #629: OP reg,mem már 2 micro-op Intel-nél. Most hivatkoznék megint a fenti IDCT-kódomra, sokszor elemi utasításoknál sem férnek el a konstans-ok a 8(/16) XMM-registerbe.
  Igen, kb. annak felel meg, aminek leírtad. Csak AMD esetében van DirectPath Double, és sokkal több minden fér bele valamelyik DirectPath-ba, K10 esetén meg már főleg).
  
  Első gondolatom a cikk után az volt, hogy vagy nagyon rááltak a server-piacra, vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.
  
  [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