Te aztán beleástál a témába
Tetszik a cikk, csak néhol hiányos volt hozzá a tudásom.

én is csak lestem mint pocok a lisztben...

azt lehet tudni, hogy milyen foglalat lesz?
gondolom már csak DDR3-at fog támogatni

Bármilyen közel vagy valakihez, végtelen a távolság köztetek.

Csak DDR3, és itt megtalálod a különböző foglalatokat: [link]

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Hümm. Még csak 'félúton' vagyok, de van itt egy kis gond.

"A HT implementálása mivel jár? Jól jönne, ha kicsit hosszabb lenne a futószalag, hiszen a Core 14 lépcsős csővezetéke nem ad elég teret a HT-nek."
Nomost tudtommal a HT főleg keresztmetszetbeli, nem pedig hosszirányú követelményeket jelent. Mit kell ez alatt érteni?

Sőt, tovább.
"Az OoO végrehajtásnak, ütemezésnek javulnia kell"
A HT pont az OoO határainak megkerülésére szolgál, a kihagyott 'lyukakat' tömi tele. Abszolute semmiféle ilyen irányú kényszert vagy összefüggést nem érzek.

Mégmás. A P4 HT legfőbb hibája tudtommal leginkább a brutálisan alultervezett L1DCache volt, nem VE.

[ Szerkesztve ]

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Látszik, hogy ez érdekel.
Jó lett, de néhol magas nekem...
Viszont a következtetésekkel egyet értek.
Csak az ütött egy jó nagy szöget a fejembe, hogy kivel akar versenyezni az Intel, vagy lefordítva, mit akarnak vele előállíttatni, és mihez.

kösz
látom lesz foglalatkavalkád megint

az integrált memóriavezérlő miatt nem lehet az lga775-öt megtartani?
mert gondolom nem a ddr3 az oka, az van már most is

Bármilyen közel vagy valakihez, végtelen a távolság köztetek.

Ha nincs elég buborék, akkor a HT nem tud hatékonyan működni. Hosszabb futószalag mellett több buborék keletkezhet, amikor az egyik szálon vmi miatt beállt a forgalom.

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Az IMC és a QPI miatt nem lehet megtartani az LGA775-öt, ezekhez a kapcsolatokhoz több kivezetés kell.

[ Szerkesztve ]

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Hijjnye de ott van a czikk!!!
Azért hiányolom azt hogy a FR-FT-ről nem esik benne szó!!!

[ Szerkesztve ]

Banya csak 1 van

Bocs, de ez nem tűnik túlzottan logikusnak. Itt a 'buborék' alapesetben szélességbeli hiányosságra utal, azaz a max. - hasraütés - négyes IPC helyett a tipikus egyre. HT-vel kettőre.
Itt a hossz csak a kihasználatlan lépcsők számát növeli feleslegesen, illetve az ugrás-előrejelzési hibák kapcsán a szeméthalmokét.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Több oldalon is olvastam, hogy a QPI a Bloomfield kiváltsága lesz, desktop prociknál megmarad a hagyományos FSB. Mi ebből az igazság?

Az eddig kiszivárgott nem hivatalos infók alapján Bloomfield és fölötte lesz QPI mert több procis rendszer csak azokból fog épülni. Az FSB szerintem nem lesz, máshogy lesz megoldva, legalábbis ezek alapján nekem ez jön le.

[link]

Fless: ezen az oldalon még van pár jó ábra: [link]

[ Szerkesztve ]

Naszal, az előbb hülyességet magyaráztam. Már kicsit régen volt, amikor erről olvastam.

A regiszterfile méretének növekedése miatt mindenképpen növekedni fog a futószalag hozza, mert a regiszterelérések ideje növekszik, és ezt kompenzálni kell a futószalagban is. Ennyi lenne a lényeg.

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

#3. hsz, a hkepcen ott vannak a slide-ok, QPI lesz mainstreamben, a Bloomfieldhez kell majd északi híd is.

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Rive-nak igaza van. A HT (SMT) a wide execution engine-nel jon jol. Mert akkor vannak a buborekok ha egy thread nem tudja kithasznalni az EE-ket. Pl. egy FP heavy kodnal az integer egysegek egy resze nem csinalna semmit. HT-vel az kihasznalhato. Nem kell hosszabb pipeline. A cel az hogy kevesebb buborek keletkezzen. Ha meghosszabitod a pipeline-t akkor amit az SMT-vel nyernel azt elveszted a hosszabitassal.

[ Szerkesztve ]

Privat velemeny - keretik nem megkovezni...

#13.
Átírtam ezt a részt, annyit azért megjegyzek, hogy ez nem egy cikk, hanem a saját hülyességeim, szal azt írok bele amit csak akarok mégha félrevezető is.
De nem vagyok köcsög, ezért átírtam.

[ Szerkesztve ]

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Így már OK lehet. Nem ismerem ugyan eléggé a kurrens alacsonyszintű megoldásokat, de hirtelenjében több lehetséges kerülőutat is látok, és nem hiszem, hogy egy ennyire korlátozott méretű full-asszociatív tár ne lehetne kellően gyors.

Bár ez már csak agymenés részemről.

Príma írás

[ Szerkesztve ]

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Vki elmagyarázná, mi az a processzor büntetés rossz elágazásbecslés esetén?

https://www.coreinfinity.tech

még jó hogy most vettem új gépet
bár ez egy ideig elég lesz (remélem)

[ Szerkesztve ]

Bármilyen közel vagy valakihez, végtelen a távolság köztetek.

Most akkor a Bloomfieldben lesz integrált memvezérlő, vagy sem? Az általad linkelt blokkvázlatok szerint igen, de a linkelt cikk ezen vázlata alapján nem.

[ Szerkesztve ]

Elég valószínű, hogy a Nehalemben számottevő meghosszabbításra kerültek a futószalagok, és éppen ennek kompenzálására szükség is volt az SMT-re.

Ennek egy következménye, hogy - a NetBurstös időkhöz hasonlóan - az SMT nélküli változatok (lásd "up to x thread" jelölések a HKEPC-n) némileg lassabbak lesznek taszkváltásban, mint az AMD aktuális procija. (Persze ezt az egyszerű felhasználó úgyse nagyon érti, viszont a magas órajel annál meggyőzőbb lesz a számára.)

Valjon hoz annyi újítást ez a Nehalem, h érdemes legyen kivárni? Sztem nem. Megint a szokásos dolog: Új proci?=új lap>>sokaknak új ram is. Nem egyszerű
Az ebben a hónapban megjelenő penryn széria tagjai is olyanok, h VALÓDI otthoni környezetben VALÓS alkalmazásoknak is bőven sok. Elég lesz gyűjteni majd a százezres vga-ra is

Az álmaim rabja vagyok, de tetteimben szabad ember...

Még egy dolgot megjegyeznék: a képek alapján az Intel csak a belépő/mobile szegmensben tervezi a - kisebb teljesítményű - integrált grafikus mag bevezetését. Ezzel szemben az AMD két irányban indulna ezzel: 1., hasonlóan a belépő/mobile szegmensben, 2., magasabb osztályban GPGPU alkalmazások számára. Utóbbi szegmensben (a diszkrét grafikus megoldások mellett) az Intel a Larrabee-vel fog versenybe szállni.

Elég valószínű, hogy a Nehalemben számottevő meghosszabbításra kerültek a futószalagok
Erre igazán írhatnál valami indoklást is. Ugyanis semmi szükségük efféle brutális áttervezésre az IMC, HT meg a többi mellett. A jelenlegi taktikájuk meg inkább arról szól, hogy egyszerre csak egy-egy részegységet forgatnak fel gyökeresen, és kifejezetten tartózkodnak a túl nagy lépésektől.

Szóval én itt mag dolgában inkább egy 'szimpla' HT-vel vadított C2 -továbbfejlesztést várok, de semmiféle 'számottevő meghosszabbítást'.

[ Szerkesztve ]

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Sziasztok!

Grat az íráshoz!
Lenne nekem is 1-2 feltevésem: a HKEPC oldalán [link] az utolsó képen a QPI-t csak a min. 2db CPU-t tartalmazó konfigban mutatja. Az valószínű, h a 1366-os alaplapban lesz 2 procis változat is, de valyon a 1160-as Lynnfield vagy a Harperdale is tudni fog ilyet? Szvsz ha több proci lesz 1 rendszerben, az jobb teljesítményt tudhat majd.
Pl. az 1db 4magosnál jobb lehet a 2db procis 2magos változat?

Köszönöm, h leírtad ezt! Kellet már nekem egy "összkép" és ráadásul magyarul is van(meglepő )!

Az Intel már rég megmondta hogy 32nm alatt nem igazán látnak fantáziát abba hogy nagyob teljesítményű GPGPU egységevel integrált CPU-t készítsenek, 1xűen ez 45nm mellett túl nagy magméretet szülne és túl nagy hőtermelést. 45nm-en az Intel csinál mobil és desktop mainstreambe is integrált GPU-s megoldást, de ezek igen nagy valószínűséggel kis teljesítményűek lesznek, hasonlóan a mostani alaplapi chipsetben található GPU-kat. A cél itt még nem a középkategória, hanem csak a belépő szint, ahogy az alaplapi chipseteknél. A cél ezekkel inkább csak az hogy bevezessék a piacra ezt az integrált formát, hogy elindulhasson a software fejlesztők részéről az új technológia beépítése, ahogy ez SSE-knél is megszokott.

Az AMD ahogy én ezt látom most idővel változtatott az álláspontján és követi az Intel elképzeléseit, ami szerintem helyes döntés. Anno a Bulldozer még 45nm-esnek készült volna 2009 év közepi megjelenéssel és nagyobb teljesítményű APU-nak szánták. De most már ugyanerre az időpontra a Swift került ami hasonlóan kisebb GPU teljesítményű lesz mint az Intel 45nm-es Nehalem alapú mainstream modelljei és inkább csak a technológia bevezetése, elfogadtatása a cél, az hogy legyenek majd softwarek amik a későbbiekben támogatni fogják. A Bulldozert pedig eltolták 2010-re, gyanítom azért mert addigra már az IBM-mel együttműködve nekik is lehet 32nm-es gyártásuk és azon már reálisabban lehet nagyobb teljesítményű APU-k integrálni a CPU mellé. Az hogy belátták 32nm kell egy jobb APU-hoz szerintem helyes út, az Intel 45nm-en ebbe bele sem akart vágni mert előre látták reménytelen.

32nm-en 2010-ben mind az Intel, mind az AMD már kellő számú tranzisztort pakolhat egyetlen lapkára ahhoz hogy megfelelő teljesítményű CPU-t és egy középkategóriás GPGPU-t integrálhassanak. Nem hiszem hogy ezek a megoldások elméleti maximális teljesítményben jelentősen el fognak térni egymástól. A kérdés inkább az lesz mely terméknek hogy fog alakulni a software támogatottsága, mely megoldást fogják a software fejlesztés beépíteni az alkalmazásaikba, ahogy most az SEE támogatásoknál teszik.

Hisz a GPGPU szerepe nem csak az hogy "különálló" grafikai egységként játékok futtatásánál használni lehessen őket, hanem mivel integrált részei a CPU-nak, ezért a számítási teljesítményüket akár mint egy SSE kiegészítést a software fejlesztők a hétköznapi alkalmazásokban is felhasználhatnák.

Az Intel már évek óta dolgozik a software részen is hogy olyan compilereket, software fejlesztési eszközöket, környvtárakat adhasson a fejlesztők keze alá, amivel a párhuzamos feladatvégrehajtás minél nagyobb mértékben tudná a hardwareben rejlő kapacitásokat kiaknázni.

Köszi.

https://www.coreinfinity.tech

Azok a régi vázlatok a pcwatch japán oldalról vannak, és vmikor 2006-ban készültek, a HKEPC-nél friss slide-anyagból készült a hír, szal inkább ennek hiszek.

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

A pcwatchos nem olyan régi, 1.5 hónapja tavaly november 18.-án kerültek ki a netre. A képeken is rajta van hogy 2007-esek. Épp ezért a kettő között nagy különbség nem lehetne, max a informátorok pontossága térhet el, de azt nehéz lenne eldönteni melyik a hitelesebb. Ezek még most csak kiszivárogatott dolgok, mindkettőt úgy is érdemes kezelni. A tavaszi IDF-en az Intel biztos többet el fog majd árulni a szerver Nehalemről, az őszi IDF-en pedig már a mainstream Nehalemek és Larrabee lesz nagy valószínűséggel a fő téma. Azon sem lepődnék meg ha bemutatnának egy működő 32nm-es Westmeret, hasonlóan csak fellebbentve róla a fátylat, ahogy tavaly ősszel a Nehalemmel is tették.

OK.
Én azért a most kiszivárgottnak hiszek inkább.
Az Itaniumos (meg az egész szervertémás) gondolattal kapcsolatban senkinek nincs ellenvetése?

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Itaniumban nem sokan gondolkodnak szvsz.

A mostani nem 100%-osan megbízható szinten merült fel a futószalagok meghosszabbítása az órajelnövelés érdekében. Ez egybe vág úgymond a HT újbóli bevezetésével is. (Legalábbis hogy desktopon is bevezetik.)

shabbarulez: A magmérettel egyelőre nincs baj, a Havendale MCP technológiájú, és a hírek szerint az AMD is ebben gondolkodik rövidebb távon. Persze nagyobb GPU úgy sem fér el, szóval nem tudom, mit is akar az AMD, de voltak olyan hírek is, hogy nem is egy tokban lennének. Így persze nem is igazán a desktopot célozzák vele. (Mármint a nagyobb teljesítményű változattal.) De lehet, hogy - mint írtad - ez már csak múlt idő, változtak a tervek.

[ Szerkesztve ]

Érdekes ez az Itanium kérdés. Ugye ott Intel azt mondta átugorja a 45nm-t és 2009-ben helyből 32nm-tel jönne a Poulsonnal. Ezzel az Itanium egyik nagy hibáját korrigálnák, az állandó komoly gyártástechnológia lemaradását, ami jó ideje már a Xeonnal szemben is kínos helyzetbe hozta az Intelt. Viszont ha addigra 32nm-en is lesz 8 magos Nehalem SMT-vel, akkor elég furcsa helyzetbe kerül ismét a Poulson, aminél 4 vagy több mag szerepel a korai várakozásokban. Végülis abba ugyanúgy belekerül a Quickpath az integrált memóriavezérlő, de ha hasonlóan alacsonyabb órajelen jön majd ki mint most a Xeonhoz képest, teljesítményben nem hiszem hogy a kettő között komoly eltérés lesz. Végülis az Intel majd ott fog állni két procival ami közel ugyanarra a teljesítményre képes, csak más-más "nyelvet beszél". Vajh a Sun meg az IBM termékei ellen melyiket fogja majd csatába küldeni? Szerintem az Intelnek előbb vagy utóbb választania kell mert lassan a Xeon front lesz annyira jó mint az Itanium.

"A mostani nem 100%-osan megbízható szinten merült fel a futószalagok meghosszabbítása az órajelnövelés érdekében. Ez egybe vág úgymond a HT újbóli bevezetésével is. (Legalábbis hogy desktopon is bevezetik.)"

Marmint hol merult fel? Mert ez badarsag. Semmi okuk a pipeline novelesere. Ha nincs linked akkor valamivel tamaszd mar ala legyszi mert technikailag oka nincs. Az uj dizajn a wide execution engine fele ment el ennek teljesen ellentmondana a pipeline novelese. Az hogy ha 1 max 2 stage-el nagyobb lesz semmi koze ahoz hogy orajelet szeretnenek novelni, max ahoz hogy ujra kellett igazitani az uj felosztashoz.

"Ez egybe vág úgymond a HT újbóli bevezetésével is. (Legalábbis hogy desktopon is bevezetik.)"

Ennek meg vegkepp semmi ertelme. Hosszabb pipeline eseten negalod az SMT altal hozott javulast. Minek csinalnak ezt?

Privat velemeny - keretik nem megkovezni...

"...átugorja a 45nm-t és 2009-ben helyből 32nm-tel jönne a Poulsonnal. Ezzel az Itanium egyik nagy hibáját korrigálnák, az állandó komoly gyártástechnológia lemaradását, ami jó ideje már a Xeonnal szemben is kínos helyzetbe hozta az Intelt."

Ja, viszont a masik komoly problemat meg meg jobban eloterbe hozza. Az hogy egyik itanium sem jon meg idoben. Eveket kesnek egy-egy verzio bevezetesevel.

Privat velemeny - keretik nem megkovezni...

"A HT implementálása mivel jár? Kicsit hosszabb lesz a futószalag, mert a HT-hoz több belső, fizikai regiszterre van szükség (regiszterfile a regiszterátnevezés miatt), márpedig ha nagyobb a belső regiszterkészlet, akkor annak elérése is növekszik, és ezt kompenzálni kell."

Az ok-okozati összefüggés még sántít kicsit (a többit már fentebb megbeszéltétek): a HT-hez tényleg kétszer akkora register-készletre van szükség, de nem szabad keverni a két szálét, mert pl. egy-egy szál téves becslésénél a másik szálat nem szerencsés visszarendelni az utolsó megfelelő, közös állapotba. Ehelyett célszerűbb két külön registerfile-t fenntartani, saját vezérlőlogikával, ahogy a chip-architect-es die-photo elemzés is mutatja, Northwood és Prescott esetében is. További lépcső(k) a futószalagban valóban kellhet(nek), mert a registerfile-olvasási stádium elég korai lépcsőfok, gyakorlatilag a megduplázott decode-hoz kapcsolható, és később 'sorba' kell rendezni az utasításokat (vagy az RS fogadási szélességét kell duplájára növelni), de a registerfile-hozzáférési idő ebben az esetben nem nő.
(Az ilyen típusú szélesítés a Conroe->Penryn 4->6 MB L2-nél a legszembetűnőbb, 16- után 24-way set-associative lett).

"A méret növelése jelentős terhet ró a chip komplexitására, viszont ha az ütemezés leegyszerűsítése (megkötések bevezetése, kevésbé rugalmas vezérlés) mellett döntenek, akkor az a teljesítmény rovására mehet, mégha ezzel együtt az elérhető órajel nőne is. Szóval ebben a kérdésben csak találgathatunk, én inkább az erőforrások kiszélesítésére tippelnék, az Intel tranzisztorszám büdzséjébe 45 nm-en belefér."

Ez egy SZVSZ egy nagyon jó "tipp", ami ha előbb nem (a Nehalem-nél), utóbb (valamely utódjánál) be fog következni. Egy dolog nagyon szembetűnő az utóbbi pár évben: míg az AMD felépítése teljesen kötött 3 szélességű (mert az utasításdekódolás és -végrehajtás erre van felkészítve; esetleg "nagyobb" áttervezés nélkül legfejlebb 4-re lehetne ezt szélesíteni), addig az Intel jóval szabadabban teszi-veszi és variálja az execution port-jait és azok tevékenységét, ahogy épp a 'szüksége' kívánja (volt a PPro óta 5-4-6 execution port); ehhez a portok közti (horizontális) ütemezés nagy rugalmassága kell. Az Intel legmagasabban talán az utasítások in-flight (VLIW nélküli) portokra leosztásában veri legjobban az AMD-t, jelenleg is, mert úgy tűnik, ez nála közvetlenül a portok előtt, a Reservation Station-ben történik (ami persze még több execution-port, vagy még kifinomultabb ütemezés esetén igényelhet még több lépcsőt), AMD-nél pedig már a dekódoláskor (Pack stages; nem véletlenül kapkod az AMD valami új - Transmeta? - megoldás után).

Ha így direkt rákérdezel az Itaniumra: azt jó lenne tudni, hogy azt Intel hány execution port-ig tud elmenni az utasítások in-flight utasítás-leosztásban, a fordítóprogramok segítsége nélkül.

"A Core-ban a Reservation Station 32 egyszég széles, ráadásul ez kezeli a memóriaeléréseket is, míg a P4-ben külön RS-t rendeltek a memóriaportokhoz."

Ez az információ, hogy az RS kezeli a memóriahozzáféréseket (out-of-order), honnan származik? Mert ez nagyon 'elegáns' lenne, de akkor szakítottak a PPro óta jelen levő Memory (Re-)Order Buffer-rel?

[ Szerkesztve ]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Itanium: volt arról szó, hogy közös foglalatba kerül a kétféle (Itanium és X86) proccvonal. Erről van valami hír? SZVSZ ettől függ, hogy az új cucc megmentő vagy sírásó lesz-e.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

"Marmint hol merult fel? Mert ez badarsag. Semmi okuk a pipeline novelesere. Ha nincs linked akkor valamivel tamaszd mar ala legyszi mert technikailag oka nincs."
Linkem nincs, már nem tudom, hol olvastam. Az alátámasztás az illető helyen az órajel alapos növelése volt. (Ehhez a magam részéről azt tenném esetleg hozzá, hogy meglepő módon az IBM valami hasonlót művelt a POWER6-ossal.)

"Ennek meg vegkepp semmi ertelme. Hosszabb pipeline eseten negalod az SMT altal hozott javulast. Minek csinalnak ezt?"
Fordítva lett volna: az órajel látványos növelése érdekében növelnék hosszt, és ennek "mellékhatásai" csökkentésére vezetnék be újra az SMT/HT-t (amúgy is jól hangzik).

Aztán persze lehet, hogy az egész csak üres spekuláció.

[ Szerkesztve ]

Már vártalak.
Fantasztikus, de elsőre megértettem amit írtál.

"Ez az információ, hogy az RS kezeli a memóriahozzáféréseket (out-of-order), honnan származik? Mert ez nagyon 'elegáns' lenne, de akkor szakítottak a PPro óta jelen levő Memory (Re-)Order Buffer-rel?"

Hoppá, némileg igazad van. Az teljesen kiesett. BTW nemtod a méretét?

De igazából csak a fogalmazás nem volt egyértelmű, úgy értettem, hogy az RS-ben tárolódnak a memműveletek (micro-op-ok) is (az összes többivel együtt), amíg meg nem érkeznek az operandusok. A MOB utána már csak az OoO load/store-okért felelős.

szerk: viszont a P4-ben van egy ALU/FPU ütemező, és külön egy mem-ütemező, ezen "csüng" a load és a store végrehajtó, és így kerül a MOB-ba az eredmény.

[ Szerkesztve ]

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Erről nem hallottam.
Arról viszont igen, hogy a POWER7-nek és az AMD nemtom melyik procijának közös lesz a foglalata.

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Tudtommal a POWER6 futószalagja ugyanolyan hosszú, mint a POWER5-é, csak "kiszedték" belőle az OoO végrehajtást.

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

"Intel common Itanium Xeon platform" szavakra keresve dőlnek a találatok.

[ Szerkesztve ]

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Na igen, 2004-ből származik a hír:

"Our goal is by 2007 to have Itanium- or Xeon-based systems using the identical components",

"He said the first chip that could conceivably be designed to be interchangeable would be the Itanium 2 multicore chip, code named Tukwila, which is expected around 2007."

Tukwila... Már 2008 van.

Ha ez bekövetkezik, akkor az mit jelent majd? Olcsóbbá akarják tenni az Itaniumra épülő rendszereket. Érdekes lesz majd látni Xeon (Nehalem) vs Itanium tesztet azonos tesztkörnyezetben, ha ott árban és teljesítményben is kikap az Itanium, akkor megásták a sírját.

[ Szerkesztve ]

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

"Fantasztikus, de elsőre megértettem amit írtál."

Ezért nem logout-ozok (egyelőre ) Viszont igyekszem változni.

"BTW nemtod a méretét?

Az Intel-nek nem kenyere a pontos specifikáció-közlés. Talán ebben vannak használható információk. (15. oldal ,a szerző neve és munkahelye hitelesítheti a prezentációt.)

[ Szerkesztve ]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Hát most lestem egy nagyot!

Kíváncsi vagyok mi fog ebből kisülni.

Eddig úgy tudtam hogy az IBM kiszállt a procibizniszből, de ezek szerint én vagyok a buta.

Sic Parvis Magna