Gyurkity Péter

Az AMD és az Intel is ősszel gyorsít

Mindkét processzorgyártó a harmadik negyedévre ígéri újdonságait, amelyek tovább gyorsítják majd az asztali számítógépeket. Az Intel 40 százalékos ugrást emleget, mégpedig a játékoknál és a munkaállomásoknál.

Henri Richard, az AMD értékesítési és marketingigazgatója egy interjúban beszélt cége terveiről, többek között az új asztali processzorok várható érkezéséről. Elmondása szerint a Barcelona sorozat a harmadik negyedévben rajtol majd el, és ez a fejlesztés nem a meglévő példányok csiszolgatását, hanem egy alapjaiban megújuló generáció felbukkanását jelenti, amely lényegesen jobb teljesítmény/fogyasztás mutatót produkál majd a jelenlegi változatokhoz képest.

A negyedik negyedévben, vagyis az év vége felé érkezik a Barcelona asztali verziója, ikermagos és négymagos változatban, hogy az otthonokban is megdobja a számítógépek teljesítményét. Ez némi csúszást jelent a korábbi tervekhez képest, hiszen eredetileg a második negyedévben, vagyis legkésőbb nyáron szerették volna piacra dobni a szerverekbe és asztali gépekbe szánt sorozatot, ám reményeik szerint ez még mindig elegendő lesz ahhoz, hogy felvegyék a versenyt a vetélytárs új fejlesztéseivel, amelyek szintén ősszel bukkannak majd fel. Szükség is lesz erre, hiszen az Intel már a 45 nanométerrel kacérkodik, miközben erősen kérdéses, hogy az AMD egyetlen negyedév alatt megfelelő mennyiségű chipet tud majd leszállítani.


Az Intel egyelőre meglévő Core 2 Extreme sorozatának felső határait igyekszik kitágítani. A QX6800 jelzésű processzor érkezéséről már a hónap elején beszámoltak, ám most egy újabb változat megjelenése van napirenden, amely QX6850 jelzéssel, 1333 MHz-re nőtt FSB-vel bukkan majd fel a boltok polcain. A jellemző fogyasztás (TDP) 130 watt, a másodszintű gyorsítótár mérete 8 MB, az órajel pedig 3 GHz - az asztali zászlóshajó 999 dollárért lesz kapható, szemben a QX6800 jelenlegi, 1199 dolláros árával.

A processzorgyártó eközben a Penry legfontosabb előnyét ismertette, amely állításuk szerint a játékoknál 40, a munkaállomásoknál 45 százalékos gyorsulást eredményez majd a jelenlegi leggyorsabb négymagoshoz, vagyis a Core 2 Extreme QX6800-hoz képest. Mindez a kisebb csíkszélesség, illetve az új tranzisztortechnológia eredménye lesz, valamikor a második félévben.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • BiroAndras #41
    Szerintem is valami ilyesmik lehetnek az okok:
    1. A P4 celeron rettenetesen lassú. Ilyenen láttam akadozni divx lejátszást is (nem HD), ami azért már elég durva.
    2. A P2 korszakban a cache-optimalizáció nem sokat számított, ma viszont az egyik legfontosabb dolog. Óriási sebesség különbséget jelenthet csak az, hogy hogyan és milyen sorrendben olvasod az adatokat a memóriából.
    3. Valami gond van a mérésse.
    4. Valami, amire nem gondoltunk.

    Amit tehetsz:
    1. Nézd meg a progit egy Core2-n, vagy X2-n. Mindkettő szanaszét alázza a P2-ket minden szempontból. Én nemrég pár régi P1-P2 korszakban írt progimat néztem meg csak egy vacak A64 3000+-on, és azok az emlékeimhez képest embertelen gyorsuláson mentek át. Pl. az egyik a régen 10-20 másodpercig tartó számolást valós időben produkálta.
    2. Nézd át a kódot, és igazítsd a mai igényekhez. Főként a memória elérést érdemes átnézni. A legfontosabb, hogy legalább 32-bites egységekben olvass, és 32-bites regiszterekkel számolj, a tömb elemeket növekvő sorrendben olvasd, és akkora adatblokkokkal dolgozz egyszerre, amik bőven elférnek a cache-ben.
    3. A mérésre inkább használj RDTSC-t, az sokkal pontosabb és megbízhatóbb, mint a rendszeróra (de kétmagos prociknál vigyázni kell vele).
  • bvalek2 #40
    (Részben) visszaadtad a hitemet az informatika fejlődésében :)
  • dez #39
    A P4 viszonylag lassú FSB-s memóriaelérésének nagy késleltetése miatt erősen rászorul a nagy L2 cache-ekre. A Celeronban meg pont ez a nagyon kevés (meg talán még a L1 is kevesebb, ha jól emlékszem, meg talán más belsőbb dolog is le van butítva), így "ki van herélve" szegény.
  • bvalek2 #38
    Nincs :) Eredetileg oprendszert akartam írni assemblyben, aztán amikor könnyűnek találtattam a feladathoz, akkor legyártottam belőle a tesztprogramot, hogy ne vesszen kárba az addigi munkám.
  • bvalek2 #37
    nem chache, hanem cache...
  • bvalek2 #36
    Tényleg, a mikrokód (bocsi, én nem figyeltem). Jó lenne valami mikrokód upgrade, amivel Alpha procit lehetne varázsolni a Pentiumból

    Ugrásbecslés, chache meghülyülés, ezekben lehet valami. Kézzel írt assembly az egész, és hát én természetesen nem igazítottam chache-line határra a subrutinokat, meg az adatokat...

    A Celeronom egyébként következetesen P4 generációnak mutatkozik be, csak sokkal kisebb chache-sel. Van valami alverzió, amiből tudni lehet hogy csak Celeron, de állítólag HyperThreadingot is tud, csak le van tiltva benne (CPUID utasításkor a visszaadott HT flag aktív).
  • dez #35
    Figyeltem, nem OS alatti fullos emulációra gondoltam, hanem arra, hogy esetleg maga a proci pl. már natívan nem létező (mármint a belső RISC kódra fordítós/bontós változatban sem) utasításokat emulálja (némi BIOS segítséggel mondjuk). De ilyesmi inkább csak floating-point kóddal fogdulhatna elő. (Pl. a 68040 így emulálgatta a 68881/2 kódot, ha nem saját FPU-s kódot futtattak, meg azokat az utasításokat, amiket eleve nem támogatott natívan.)

    Az is lehet, hogy a kódod meghülyíti az ugrásbecslést, vagy a cache-kezelést, vagy más efféle.

    Egyébként a P4 Celeront nem kellene P4-nek mondani, mert igencsak nagy a különbség a kettő között.
  • fade2black #34
    most van oprendszer vagy nincs?
  • bvalek2 #33
    "beljesében" (C) bvalek2, a Nyelvujító
  • bvalek2 #32
    Jól van, te sem figyelsz :)

    nincs emulálva semmi! nincs operációs rendszer! a csupasz vason fut a program! floppyról bootol a programom. átkapcsol védett módba (a Windows XP is ebben a módban fut). Normál, 32 bites, általános integer és memóriacímző utasításokat használok, amik már 386-os óta megvannak. ezeket használják a programok az esetek 80%-ában (a P4-en is). Az igazi hardverórát olvasom, azt, amit IO regiszterműveletekkel lehet elérni.

    ugyanaz a módosítatlan kód picit lassabb P4-en, mint P2-őn. azt tudom, hogy mindkettő beljesében egy RISC dolgozik, de ennyire nehéz lenne P4-en értelmezni ugyanazt a kódot? én is nagyot néztem, sok tesztet csináltam után, hogy biztos lehessek benne.

    Direkt kikapcsolom a megszakításokat a futásidőre, nehogy az APIC okozzon bajokat. Még a lapozást is kikapcsoltam, nehogy az MMU miatt legyen eltérés. Sőt, legmagasabb processzorprivilégiummal fut a program, tehát még jogosultságokat sem ellenőriz (hogy pl. van-e jogom IO művelethez, vagy sem). Annyira tudok még gondolni, hogy talán valami extra cache utasítással be kellett volna olvastatnom talán a memóriaterületet a cache-be? Ezt lehet hogy egy oprendszer elvégzi automatikusan... de ez csak tipp, megpróbáltam már utánanézni, hogy van-e ilyen, de nem találtam rá utalást az inteles dokumentációban.