Hirdetés

  2. Fórumok
  3. Processzorok, tuning
  4. Intel Tejas: törölve!
  5. (téma lezárva)
Keresés

Aktív témák

  • #173 Chain|Q tag perla #153
    #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
    #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
    #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