SG.hu·

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.

Kapcsolódó cikkek és linkek

Hozzászólások

Jelentkezz be a hozzászóláshoz.

© BiroAndras2007. 04. 22.. 00:39||#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).
© bvalek22007. 04. 19.. 13:47||#40
(Részben) visszaadtad a hitemet az informatika fejlõdésében 😊
© dez2007. 04. 19.. 11:18||#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.
© bvalek22007. 04. 19.. 09:02||#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.
© bvalek22007. 04. 19.. 09:01||#37
nem chache, hanem cache... <#email>
© bvalek22007. 04. 19.. 09:00||#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 <#vigyor2>

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).
© dez2007. 04. 18.. 22:05||#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.
© fade2black2007. 04. 18.. 21:12||#34
most van oprendszer vagy nincs?
© bvalek22007. 04. 18.. 15:04||#33
"beljesében" (C) bvalek2, a Nyelvujító <#banplz>
© bvalek22007. 04. 18.. 15:01||#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.