Informatika és tudomány

Gyurkity Péter

Hatmagos chipek az Inteltől

Az AMD hárommagos processzorai után azt hittük, hogy nem érhet újabb meglepetés minket, de tévedtünk. Az Intel több forrás szerint több hatmagos változatot tervez piacra dobni, egyelőre a szerverekhez.

A források szerint a kiválasztott család a Xeon MP "Dunnington", amelynek tagjai - jelzésüknek megfelelően - a több processzorral dolgozó, vagyis multi-processor (MP) szerverekbe kerülnek majd. Ezek már tartalmazzák a cég által régóta ígért Quick Path Interconnect (QPI) buszrendszert is, ám arról megoszlanak a vélemények, hogy pontosan hogyan is festene a hatmagos szerverchipek belső felépítése. Lássuk, milyen részleteket közöltek eddig a jól értesültek.

Elsőként a PCWatch, majd ezt követően a Virtualization Journal számolt be a speciális processzorok fejlesztéséről. Úgy vélik, hogy a gyártó már az idei év második felében piacra dobná ezen megoldásokat, hogy megfelelő alternatívát kínáljon a már kapható négymagos Opteronokkal szemben, amelyek eddig sem tudták kellő gyorsasággal elözönleni a szerverek szegmensét. Ez azt is jelentené, hogy tovább csúszik a Xeon és az Itanium platformok egyesítése, jóllehet ezt az Intel a Tukwila processzorok révén 2008 végére ígérte. A jelek szerint erre nem kerül időben sor, ehelyett jönnek majd a hatmagosok.

Ezek a chipek természetesen bizonyos területeken maguk mögé utasítják majd a riválisokat, bár az kérdés, hogy a fogyasztás miként alakul majd, vagyis megfelelő szinten tudják-e majd tartani az étvágyat. Egyesek úgy vélik, hogy három ikermagos chipet házasítanak össze, hasonlóan az első négymagosok felépítéséhez, míg mások hat külön magra számítanak egyazon szilíciumlapkán. A másodszintű gyorsítótár mérete 16 MB-ra ugorhat, a Dunnington család pedig kizárólag a szerverek szegmensében teljesít majd szolgálatot. Nem zárják ki az asztali vonalon történő megjelenést sem, ár erre vonatkozóan konkrét információ nem látott napvilágot.

Az Itanium és a Xeon az előzetes tervek szerint 2009-ben már ugyanazon platformra épülne, mindkettő átvenné a QPI-buszt. A Nehalem mikroarchitektúra részeként ez utóbbi mind a szerverek, mind pedig az asztali gépek vonalán megjelenne - jövőre meglátjuk, addig is várjuk a hatmagos erőművek felbukkanását.

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 #57
    Tudom, hogy van ráció az ilyesmi tömörítésekben, de szerintem nem mai gépeknek való feladat. De ha már elkezdett vele foglalkozni, hát csinálja (ne csak beszéljen róla). Pihenésképp tőlem tervezzen új szuperprocit, de azért talán nézzen utána, miért nem lehet pl. 3 GHz-en hajtani egy 486-ost (mai gyártástechkel sem). :)
  • bandee1 #56
    TAKARITSÁTOK MÁR LE EZEKET A TELEBASZOTT HAZUG POLITIKAI FIBASZOS REKLÁMOKAT INNEN!
    Az SZDSZ egy náci párt.
  • RealPhoenixx #55
    Dez: ne bantsad, en csipem ot :)

    NB: a tomoritot pedig mar parszor atgondoltam, es valszeg igen, lehet faint csinalni, bar sztem kicsit tul buzgon rakapott es elszamolta a becsult dolgokat, szval lehet hogy majd beszallok, ha a sajat dolgaim rendbe lesznek
    Asus P5E; Q6600@3,4GHZ; Dragon 800MHZ 8G, Asus 8600GT; Samsung 1,25T; Dragon haz; Cooler Master M620; Logitech G5; Schyte Ninja 1100 RevB; Canon LBP810 & Lide 600F; LG L226WTQ & Belinea 21\"; NEC RW
  • dez #54
    Ja, hogy te vagy az, és ez az új mániád... ;) Sok sikert!
  • dez #53
    Lehetne akár a L2 is 16 MB, mert nem a jelenlegi chipekhez hasonló MCM (multi-chip module) lesz, hanem monolítikus. De mindegy, mert tényleg a köv. hsz-edben leírt felépítés valósul meg:


    De van itt nagyobb hiba is a cikkben: Ennek a chipnek köze nincs a Quick Path Interconnecthez. Nem is lehetne, mert lábkompatibilis a mai 4-magosokkal, amik a szokásos Inteles FSB-t használják. A QPI a Nehalemekkel jön, új tokozásokban.
  • Frayer #52
    igen :)
    pontosan ezt akarom megcsinálni
    Nemsokára lesz egy xilinx edk fejlesztő parkom, ha meg lesz rá a pénzem.
    Közben meg majd tanulgatom a HDL leíró nyelveket és nézegetem a procik forrásait.
    Nem mondom hogy egy két hónap és lesz eredmény, de kezdetnek nem rossz.
    Lehet, hogy egy két éven belül már készen is lesz a busz rendszer.
    Egyáltalán nem bonyolult a működési elv, sőt, már meglévő dolgokra épül.
    Ha valaki betársul hozzám, és hozzá tud adni valamit az mindig jól jön.
    Ebből lehetne akár egy komolyabb project is később.
    A legegyszerűbb útja meg az lenne hogy fpga-ra fejleszteni előbb, és ha már minden jól működik kicsiben, fpga-n, akkor lehetne azzal foglalkozni hogy valamelyik chip gyártó támogatás képpen legyártja a prototipusokat.
    De most még lázasan dolgozok a tömörítő programon, amit beígértem.
    Tudnék mutatni képeket is most de még korai lenne, egyelőre még a grafikonos analizáló rendszeren dolgozok, kb 30 % van készen.
    Még kell kb 2-3 hét :( Ha ugyan ilyen lázsan dolgozok majd , de nem valószínű most hogy ilyen jó lett az idő.
    I love to walk in the rain, because no one knows im crying
  • dez #51
    De miért csak fantáziálsz róla? Szerezz egy FPGA IDE-t, és kezdd el megvalósítani. Oda persze nem fog elférni 1024 mag, de kezdetben jó lesz kevesebb is. :)
  • Frayer #50
    Csak azért használnék ütközésvizsgáló rendszert, mert így bármelyik mag , bármikor igény szerint férhetne hozzá a buszhoz, igaz így lehetnek ütközések, de ezt csökkenthető ha párhuzamossá tesszük a forgalmat, ha meg mégis ütközés van akkor egy két ciklus várakozás.
    A többi elvű forgalom vezérlés szerintem lasabb lenne, mivel azok olyan mint egy társas játék, hogy amíg az egyik dob, a többi várakozik.
    Egy ilyen ezer magos procinál szerintem nem megengedett a magok üresjárása, nem várakozhatnak folyton.
    Az ütközésed rendszerben meg csak akkor várakoznának véletlen ideig amikor ütközés van.
    Az meg az adatforgalomtől függően csak nagyon csekély elhanyagolható esetben valósulna meg. Mivel több adatút is lenne, ez egy párhzamos rendszer lenne.
    I love to walk in the rain, because no one knows im crying
  • Frayer #49
    igazad van, címbusz helyett adatbuszt értettem, csak hanyag vagyok , nem lesem vissza mit írok, de azért remélem érthető mit akarok írni.

    Azt akartam mondani, hogy mivel tegyük fel hogy 1024 db mag van a rendszerben, ez alá biztos nem lenne elég 4 gigabájt, tehát 64 bites lenne a címbusz.
    És hogy minél gyorsabban történken a blokkok belapozása , minél nagyobb, szélesebb legyen az adatbusz.
    Ehez persze új memória vezérlőre van szükség.
    Én úgy csinálnám, hogy minden magnak lenne egy kis szelete a memóriából, pár megabájt, amihez közvetlen hozzáférne, az egész memória megosztott lenne, és ha egy másik mag is hozzá akar férni a megosztott memóriához, maga a busz intézné a megvalósítását is, a buszra kiküldött kérelem a cím szerint lesz eljutatva ahoz a maghoz amelyik a bekért memória blokkot kezeli közvetlenül, de ott nem megy át a maghoz , hanem közvetlenül a busz kiírja a memória címbuszára a kérelmet, és a proci és memória útvonal szemaforját stop-ra kapcsolja addig amíg nem jön vissza a kiolvasott adat, ha visszajött, küldi vissza a busz a kérő magnak, aztán visszabillenti a szemafort és újra jöhetnek az újabb load, store kérelmek.
    Az egész úgy működne mint egy vasúti forgalom irányító rendszer.
    Egyszerű, gyors, hibakorrekcióval, ha ütközés van azt érzékeli a rendszer mert a buszra írt adatokat mindig visszahalgatják a magok, ha baj van , várnak egy pár ciklust és újra próbálkoznak.
  • dez #48
    "Persze nem 32 bites címbusszal, hanem 64 el, és az adatoknak sem ártana egy 128, vagy 256 bites címbusz, sokkal gyorsabban lapozna be nagyobb adattömböket az áramkör a cache-be"

    Izé, itt egy kicsit keverednek a fogalmak. A címbusz szélessége a fizikailag megcímezhető memória méretét szabja meg, nem az adatmozgatási szélességet. Utóbbit az adatbusz szélessége határozza meg. (Bár ezek egy ideje multiplexáltak.)
További bejegyzések a fórumban...