SG.hu·

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ó.

Kapcsolódó cikkek és linkek

Hozzászólások

Jelentkezz be a hozzászóláshoz.

© dez2005. 05. 18.. 14:21||#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 , í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
© BiroAndras2005. 05. 18.. 14:10||#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.
© mainruler2005. 05. 18.. 12:30||#45
Természetesen nem. 😊
Ne isteneítsünk termékeket. Használjuk õket. Arra valók.
© dez2005. 05. 17.. 23:01||#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.
© dez2005. 05. 17.. 22:49||#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.
© droland2005. 05. 17.. 22:15||#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***...
© dez2005. 05. 17.. 21:21||#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.
© dez2005. 05. 17.. 21:03||#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ó.
© dez2005. 05. 17.. 21:02||#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û.
© mainruler2005. 05. 17.. 20:32||#38
Nincs jobb. Épp ezt próbálom tudatosítani.