Gyurkity Péter

A Pentium III-ra hasonlítanak majd az Intel ikermagos processzorai

A processzorgyártó egyik vezető beosztású tisztviselője megerősítette, hogy a második generációs ikermagos chipek nem támogatják a Netburst technológiát, így a Pentium 4 helyett inkább a Pentium III architektúrára hasonlítanak majd.

Patrick Gelsinger, az Intel Digital Enterprise Group alelnöke a Golem.de oldalnak adott interjújában beszélt a fejlesztés alatt álló termékekről, amelyben főként a második generációs ikermagos processzorok felépítéséről és újdonságairól esett szó. Elmondása szerint ezeknél a chipeknél nem törekednek a magas órajel elérésére, hanem - erősen az AMD módszerére emlékeztető módon - inkább megpróbálják a lehető legnagyobb sebességet kicsikarni a jelenlegi órajelből.

"A Conroe, Woodcrest és Merom kódnéven fejlesztett processzoroknál lemondunk a Netburst technológiáról" - jelentette ki az interjúban Gelsinger, arra a kérdésre válaszolva, hogy igaz-e a technológia elhagyásáról szóló mendemonda. Ez volt az első alkalom, hogy a vállalat egy tisztviselője hivatalosan is elismerte a meglehetősen nagy jelentőségű váltást. Amint arról korábban hírt adtunk, a három kódnév három különböző platformot takar: a Merom a laptopokba szánt Pentium M processzorok leszármazottja, a Conroe ennek asztali implementációja, míg a Woodcrest kifejezetten szerverekbe készül.


Patrick Gelsinger

Nem véletlen, hogy az Intel lemond a Netburst technológiáról, hiszen ezt a megoldást a jelenleg kapható Pentium M processzoroknál sem vették igénybe - ahogy az könnyen leolvasható a Pentium M és Pentium 4 chipek órajele és fogyasztási adatai közötti óriási különbségből.

"A Pentium 4 igen hosszú futószalagot rejt magában. Ez mindenképpen szükséges volt a magas órajel eléréséhez, de a fogyasztás és a teljesítmény terén nem igazán tette hatékonnyá a processzort. Az új chipek esetében ezért rövidebb futószalag alkalmazása mellett döntöttünk. Ebből a szempontból ezek a termékek jobban hasonlítanak a Pentium III processzorokra, de a Netburst néhány újítását az új architektúrába is implementálni fogjuk" - tette hozzá az alelnök, amivel valószínűleg a Hyper-Threading és virtualizációs technológiákra gondolt.

A vállalat még az elmúlt héten jelentette be, hogy a Merom és a Conroe - a Yonah és a Presler utódai - 2006 második felében mutatkoznak be, míg a Woodcrest megjelenéséről nem esett szó.

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)
  • dez #47
    Hát, ezek mind elég nyilvánvalók. De az a helyzet, hogy a 1-2 kivétellel az semmelyik játék és játékmotor nincs erre felkészítve, és kérdéses, mikor, és melyikeket fogják átírni. Egy játékon belül nem kiegyensúlyozott a teljesítmény-igény a független részfeladatok között [grafika, hang, fizika, stb.], így nem elég egyszerűen azokat párhuzamosan futtatni. (Bár biztos lesznek, akik beérik majd ennyivel.) Arra is gondolj, hogy kétféleképp kell megírni a kódot, single- és dual-core-ra is, mert még jó ideig ezek is párhuzamosan fognak futni.. :p
  • BiroAndras #46
    dez:
    Az, hogy milyen nehéz többszálú kódot írni, nagyon függ a feladattól. A legtöbb CPU igényes feladat jól párhuzamosítható. Emellett akkor is egyszerű a dolog, ha eleve több független feladatot kell egyidőben futtatni. Ez utóbbi egyre inkább jellemző az otthoni használatra.
  • mainruler #45
    Természetesen nem. :)
    Ne isteneítsünk termékeket. Használjuk őket. Arra valók.
  • dez #44
    Mondjuk ennél a 25%-nál azt is jó lenne tudni, mennyi idő 1db konvertálás. Mert lehet, hogy a kettő egyszerre jobban lassítja a P4-et kikapcsolt HT-vel, mint egy Athlont. És akkor nem sokat számít, hogy 25%, csak a saját gyengeségét kompenzálja.
  • dez #43
    Hát, nem tudom, hol nézted, nagyon rossz helyen, az biztos... :) "Értelmesből" régebbit hirtelen nem tudok, de itt van egy újabb. Egy esetet kivéve jobbal lassul a HT-s P4 a több feladattól, mint az Athlon (single és dual-magosak is). (Itt sajnos nincs olyan teszt, hogy mi lenne kikapcsolt HT-vel.)

    Ja, egyébként tényleg van nálad 25%-os gyorsulás (HT nélkülis esethez képest)? Szinte hihetetlen.
  • droland #42
    Azért azzal vitatkozom, hogy egy adott programnak KÖTELEZŐ támogatnia a dupla magot (vagy HT-t), mert nálam pl. ha egyszerre elindítok két mp3 tömörítést, mint a kettő egy 500 megás wav állomány egy ócska 3 éves programmal, akkor a HT bekapcsolása esetén 16 perc helyett 12 perc alatt lesz kész, ugyanis MAGA A WINDOWS XP oldja meg ebben az esetben a helyzetet, AMI AZT JELENTI, hogy ha maga a program is támogatná, akkor sokkal jobb lenne a helyzet.

    Más:

    Kikapcsolt HT-nél nálam pl. dvd írás, és mpeg4 konvertálás egyidőben szaggat a doom3, bekapcsolt HT-nél totál semmi sem érezhető...

    Tehát ha van is 15% lassulás valahol, az lehet, én hálistennek még nem találkoztam vele, de AMI AZ ÉRDEKES, az az, hogy én még nem láttam olyan tesztet, hogy HT-t ÚGY teszteltek volna, hogy több progit futtatnak egyidőben. Pl. 4 giga dvd film betömörítése rar-ba maximális hatékonysággal + mellette 3dmark 2005 futtatás. Sajnos ilyen jellegű tesztet, ami ezt hivatott tesztelni, azaz a HT lényegét még nem láttam, csak olyat, hogy:

    1/ HT bekapcsolva
    Winrar - x mp

    2/ HT kikapcsolva
    Winrar - y mp

    Már bocsánat, ez nem HT teszt, ez lóf***...
  • dez #41
    Mondok egy példát erre a megosztott/nem megosztott cache-re. A cache mérete ugyebár korlátozott, csak egy program-részlet (pl. nagyobb ciklus), vagy az adatok egy része fér bele. Nos, tegyük fel, két olyan program-részlet akar párhuzamosan futni, amikből egyszerre csak az egyik fér bele a cache-be. Két külön cache-nél nincs semmi gond. Osztott cache-nél mindkettőből kevesebb fog egyszerre elférni -> több hozzáférés a main ramhoz... (Vagy adott esetben L2-L3-hoz.)

    Továbbá, ha a két szál adott része egymás adataival is dolgozik, és önmagukban rövidek, jobb a megosztott cache, mert akkor könnyebben és gyorsabban hozzáférhetnek egymás adataihoz.

    Tehát, az adott program szempontjából egyátalán nem mindegy, hogy egyedi vagy megosztott a cache.

    A saját cache-sel rendelkező dual-core megoldás az első esetbe tartozik, a HT a másodikba... Így egy adott program-páros szempotjából az sem mindegy, hogy két core-on futnak, vagy egyen HT-vel.
  • dez #40
    Őőő, úgy érted, hogy akkor ne vegyünk semmit? Vagy vehetünk, de jól tapossuk meg? :)

    Egyébként szerintem pl. az Xbox procija, vagy a Cell elég jónak mondható.
  • dez #39
    "Hogy a cache osztott vagy sem, az a kód szempontjából répa."

    Ebben nem lenné annyira biztos, de vitatkozz rajta inkább Gabesttel.

    "A HT lényege épp az hogy 2 procinak láttatja magát, pont mintha 2 külön proci lenne benne. Az oprencer úgy is kezeli. Az más kérdés hogy mivel nincs 2 proci, nem mindig sikerül a párhuzamos végrehajtás, így a másik szál elég sokszor dekkol, mint az autók a piros lámpánál. Ha ződ lesz az út, majd megy tovább. Ugyanígy a 2. prg szál is."

    Köszi, de ezt eddig is tudtam... :)

    "Csak sebességbeli eltérés van a HT és a dupla mag között."

    Ebben sem lennék olyan biztos. Az "ellentmondásos" tesztek is arra vallanak, hogy ez nem ilyen egyszerű.
  • mainruler #38
    Nincs jobb. Épp ezt próbálom tudatosítani.