Aktív témák

• #173 Chain|Q tag perla #153

  2004-05-09 02:08:21 #173

  Ö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

  

  Chain|Q

  tag

  válasz perla #153 üzenetére

  Miert jo az, ha tervezel egy zsenialis procit, es a celkozonseg olyan progit futtat rajta, amire nincs optimalizalva, vagyis lassabban fut a progi rajta, mint az ellenfel szoftverhez tervezett procijan?
  
  Ez nem jo, megis ez tortent, ugyanis a P4-bol koztudottan rengeteg olyan dolog volt kihagyva, ami szukseges a megfelelo sebesseg eleresehez bizonyos ''regi progik'' eseteben. Pl. a hardveres bitforgato egyseg (ROL/ROR), vagy emlithetnem a katasztrofalis FPU teljesitmenyt is. A P4 volt az egyik leginkabb olyan proci a kozelmultban, ami optimalizalasi, ergo ezekszerint (a ti ertelmezesetek szerint) visszafele kompatibilitasi szempontbol katasztrofalis volt, es igazan csak a direkt ra keszult programok futnak rajta jol. Megis ez terjedt el a legjobban, marketingszempontok miatt. Szoval most akkor hogyis van ez?
  
  Egyebkent en programozaselmeleti dolgokrol beszelek a processzorok kapcsan, amin sporolni lehetne. Tipikus peldak a stack-kezeles az x86 procikban. Anno kezi asmhez nagyszeru volt, hogy minden stack ki-be mozgataskor modosult a veremmutato is, ma mar ez a forditoprogramok koraban felesleges, es csak plusz eroforrasokat igenyel. Ugyanez pepitaban az FPU is. Akkor ott a totalis zsakutcanak minosulo MMX, vagy a 4 privilegiumszint amibol gyakorlatilag mindenki csak 2-t hasznal. Vagy eppen a kvazi minden utasitasnal modosulo jelzobitek, amiktol nagyon nehez hatekony pipelineos optimalizalast csinalni, ha sok ugrabugra van a kodban. Ezek elhagyasatol nem lenne lassabb egy processzor, sot, gyorsabb es hatekonyabb. (lasd meg: PowerPC Microprocessor Family: The programming Environments for 32-Bit Microprocessors, Motorola, 1997, MPCFPE32B/AD) A visszafele kompatibilitas biztositasara pedig vannak egyeb (szoftveres) modszerek, mint azt mar emlitettem volt.

• #155 emvy félisten perla #153

  2004-05-08 22:15:36 #155

  Ö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

  

  emvy

  félisten

  válasz perla #153 üzenetére

  Fejtsd mar ki, hogy mikor gyorsabb 3-4x egy G5 egy Xeonnal.

• #154 perla csendes tag perla #153

  2004-05-08 20:58:42 #154

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  perla

  csendes tag

  válasz perla #153 üzenetére

  Meg valami eszembe jutott, a cikkel kapcsolatban. Irtak, hogy 24kbyte adat es 64kbyte trace cache. Legjobb tudomasok szerint a mostani procikban 12k bejegyzes van a trace cacheben, ami valojaban 80 kbyte (256 set, 8 utas, egy line 40 byte, ami 6 utasitas, 53 bit/utasitas), szal a 64kbyte az gondolom eliras, hiszen az kevesebb lenne, mint ami most van. Amennyire en tudom, 16k-ra akarjak fejleszteni, es az ugy epulne fel, hogy 512 set, 8 utas, 32 byte egy line, ez 4 utasitas lenne, vagyis 64bit/utasitas. Ez osszesen 128kbyte. Illetve ami meg kulonbseg, hogy a mostani trace cache orajelenkent 3 utasitast tud megtalalni, a tervezett uj meg 4-et.

Aktív témák