Informatika és tudomány

Gyurkity Péter

Bemutatta négymagos chipjét az Intel

A processzorgyártó lerántotta a leplet jövőre megjelenő négymagos fejlesztéseiről, és bár a következő években több újítást is ígérnek, idén még az ikermagos változatok felfuttatására koncentrálnak.

A jelenleg még fejlesztés alatt álló Clovertown kódnevű szerverchipet Justin Rattner, az Intel technológiai igazgatója mutatta be. Az eddig elkészült összesen négy példányból egyszerre kettő debütált, mivel ezek a chipek kétprocesszoros szerverekben szolgálnak majd. A technikai részletekről egyelőre mélyen hallgatnak, mindössze annyit tudtunk meg, hogy egy újabb változat, a Tigerton a négy, illetve több foglalatú masinákban érkezik, és kereskedelmi forgalomban a korábbi ígéreteknek megfelelően jövőre jelennek meg.

A gyártó eredetileg a Whitefield projekt révén szeretett volna berobbanni a négymagosok piacára, ám tervezési problémák miatt ezt törölték, és minden erővel a Clovertownra koncentráltak. Rattner elmondása szerint az elkövetkező években a magszám növelésére koncentrálnak, és az évtized végére a több tíz magból álló processzorok megjelenését is elképzelhetőnek tartják.


Justin Rattner, az Intel technológiai igazgatója

Az igazgatónak nagyotmondásban nem kell a szomszédba mennie: szerinte tíz éven belül több száz magot tartalmazó processzorok kifejlesztése is lehetséges lesz, és a koncepció révén elfogadható szinten tudják majd tartani a fogyasztást és hőtermelést. Ennek ugyanis némileg ellentmond, hogy már a nyolcmagosoknál nagy kihívást jelent a megfelelő gyorsítótár elhelyezése.

Idén azonban egyértelműen az ikermagos változatok gyártásának felfuttatása a cél. Ezekből 60 millió példány leszállítását szeretnék elérni, ami saját adataik szerint a teljes eredmény egynegyedét tenné ki. A Conroe, Merom és Woodcrest magok révén mindhárom területen, azaz a szervereknél, asztali számítógépeknél és a mobil megoldásoknál is előretörést remélnek, vagyis azt, hogy megelőzhetik az AMD helyzetének további javulását. A több száz magból álló chipek ígérete ma még elég elképzelhetetlennek hangzik, ám az biztos, hogy nem lazsálhatnak, hiszen riválisuk is jövőre tervezi négymagos processzorai megjelené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)
  • BiroAndras #132
    No, beüzemeltem az X2-t. Csináltam egy kis tesztprogit, ami 2 számolós szálat indít. Semmi mást nem kellett tennem, mint fellőni a két szálat ahhoz, hogy mindkét magot kihasználjam. Sőt, 1 szál sem 1 magon fut, hanem ugrál a két mag közt a terhelés függvényében.
  • dez #131
    "Te mondtad, hogy minden thread-hez child process is kell, hogy mentse a regisztereket (ez esetben ugye adott az 1-1 hozzárendelés)."

    Ezen a ponton én is tévedtem, nem kell mindig. Csak fork()-nál (l. #118). Úgy gondoltam, egy új szálhoz kell egy egész process-struktúra, hogy ott tárolódhassanak bizonyos dolgok (stack, program counter mentés, stb.). De nem feltétlenül kell egy egész, csak egy része (amit az alább általad felhozott AxnBeginThread hoz létre). Ilyenkor nem lesz egy valódi új process, csak egy "lightweight process". :)

    "Nem a regiszterek mentésérnek konkrét folyamatáról beszéltem, hanem arról, hogy ha mindenképp kell child process a threadhez, akkor azt is az OS intézi, nem kézzel kell létrehozni."

    Ja, értem. (Igazából jól írtad le, csak már álmos voltam. :))

    "Ez így garantáltan nem igaz. Különben 1 lefagyó progi magával rántraná az egész rendszert."

    Hát igen, így frissebb fejjel átgondolva, valóban nehézkes lenne... :) Bár, esetleg elképzelhető, hogy ilyen eseteket érzékeljen a rendszer (megszakítások is vannak, lehet pl. egy megszakításban egy számlálót léptetni, stb. - bár ez elég vad dolog lenne :)), és kirúgja azt a processt. Néha elég érdekesen viselkedik a Windows, lehet, hogy valami ilyesmi miatt? :)
  • BiroAndras #130
    "Csak akkor lenne elég processenként menteni, ha annak esetleges több threadjét nem akarjuk (preemptív) multitaskban futtatni."

    Teljesen félreértessz. Te mondtad, hogy minden thread-hez child process is kell, hogy mentse a regisztereket (ez esetben ugye adott az 1-1 hozzárendelés). Erre válaszoltam.

    "Nyilvánvaló, hogy az OS intézi ezeket. Mit gondolsz, ha nem mentené/töltené a Windows (a szálhoz tartozó stackbe) a regiszereket taszkváltáskor, mi lenne velük? Az AfxBeginThread paraméterei között szerepel is a StackSize."

    Nem a regiszterek mentésérnek konkrét folyamatáról beszéltem, hanem arról, hogy ha mindenképp kell child process a threadhez, akkor azt is az OS intézi, nem kézzel kell létrehozni.

    "Microsoft introduced cooperative multitasking (which Microsoft refers to as process multitasking) in Windows 3.0. The newest versions of Windows (Windows NT and Windows 95) include preemptive multitasking (but only between the threads of a given process)."

    Ez így garantáltan nem igaz. Különben 1 lefagyó progi magával rántraná az egész rendszert.
  • dez #129
    "Akkor meg kéne különböztetni a thread-et mint fogalma, és mint adatszerkezetet (process dettó)."

    Oké, végülis igen. A processen belüli threadet talán szerencsésebb lett volna pl. subthreadnek nevezni. Vagy az egyiket konzekvensen kizárólag "thread of execution"-nak írni (pl. #118), a másikat meg simán threadnek. (De ilyen úgysem lehet elvárni.)
  • dez #128
    "Hol javítottál ki? Nem látom."

    Kezdem azt hinni, hogy nálad nem jelenik meg minden hozzászólás... ;) Pl. #120.

    "Persze, de ettől még a probléma nem oldódik meg."

    De az a megoldás kulcsa. És lássék: a #106-os alapján egy program két threadje is futhat más-más procin is akár. De persze lehetséges, hogy itt téved a Wikipedia. (De semmiképp sem biztos.)

    "Akkor meg kéne különböztetni a thread-et mint fogalma, és mint adatszerkezetet (process dettó)."

    Csak annyit kell tudni, amit a #115-ben leírtam, de adja is magát. Persze laikusoknak így kevésbé egyértelmű. Csakhogy, a programozási fogalmakat alapvetően a programozóknak találták ki, nem a laikusoknak.

    "Implementációs kérdés, hogy a regiszterek thread-enként vagy process-enként mentődnek."

    Tessék? Csak akkor lenne elég processenként menteni, ha annak esetleges több threadjét nem akarjuk (preemptív) multitaskban futtatni.

    "Az első esetben nem kell child process, a másodikban kell."

    Ez igaz, de itt most a desktop OS-ekről beszélünk (azon belül Windowsról), nem valami egyszerűsített embedded rendszerről.

    "Win-en elég egy új thread-et fellőni (AfxBeginThread), másra nincs szükség (vagy elintézi az OS magában)."

    Nyilvánvaló, hogy az OS intézi ezeket. Mit gondolsz, ha nem mentené/töltené a Windows (a szálhoz tartozó stackbe) a regiszereket taszkváltáskor, mi lenne velük? Az AfxBeginThread paraméterei között szerepel is a StackSize.

    Viszont... Kicsit jobban utána néztem én is a thread-témának, és azt találtam, hogy van (OS-től föggően is), amikor általánosságban használják a kifejezést (lásd pl. #118), mint fogalom, és van, amikor konkrétan (egy processen belüli függvény threaddá avatása, saját stackkel, handle-lel, stb., és külön szálon futtatása, a la AfxBeginThread)... Ez persze okozhat némi félreértéseket. Rigidus is nyilván az utóbbira asszociált. (De azért 1-2 dologban tévedett.)

    Találtam egy érdekes oldalt:
    Idézetek:
    "Threads are "lightweight processes." They behave like processes in that they support an additional path of execution, but they share the same address space as their parent. Because there is only one address space, there is little need to think about IPC. It also means that a programming error in one thread can ruin data in the other thread."

    És ami főleg érdekes:
    "Microsoft introduced cooperative multitasking (which Microsoft refers to as process multitasking) in Windows 3.0. The newest versions of Windows (Windows NT and Windows 95) include preemptive multitasking (but only between the threads of a given process)."
    Wow...

    Na mindegy, szerintem tudhat futni egy process két threadje két külön procin is.
  • BiroAndras #127
    "Nem gondolod, hogy a "teljesen világos" egy kicsit túlzás, tekintve, hogy jópárszor ki kellett javítsalak?"

    Hol javítottál ki? Nem látom.

    "Ejj, nem gondolod, hogy amikor egy vita van a fogalmak nem pontos ismerete miatt, először azokat kell tisztázni?"

    Persze, de ettől még a probléma nem oldódik meg.

    "Child-processt akkor is létre kell hoznia. Mivel kell, hogy valahol tárolódhassanak a taszkváltásokkor a regiszterek, stb."

    Akkor meg kéne különböztetni a thread-et mint fogalma, és mint adatszerkezetet (process dettó).
    Implementációs kérdés, hogy a regiszterek thread-enként vagy process-enként mentődnek. Az első esetben nem kell child process, a másodikban kell.
    Win-en elég egy új thread-et fellőni (AfxBeginThread), másra nincs szükség (vagy elintézi az OS magában).
  • dez #126
    "Nekem teljesen világos a dolog."

    Nem gondolod, hogy a "teljesen világos" egy kicsit túlzás, tekintve, hogy jópárszor ki kellett javítsalak? Sőt...

    "De az alap kérdés nem ez volt"

    Ejj, nem gondolod, hogy amikor egy vita van a fogalmak nem pontos ismerete miatt, először azokat kell tisztázni?

    "hanem az, hogy a multicore procik kihasználásához az illető szoftvernek elég több szálon futnia, vagy több process-t is létre kell hoznia."

    Child-processt akkor is létre kell hoznia. Mivel kell, hogy valahol tárolódhassanak a taszkváltásokkor a regiszterek, stb.

    "Szerintem a child process és a thread nem ugyanaz."

    Ehh, olvass már légyszives! #115-118, #121.
  • BiroAndras #125
    "Jaj, hát erről is szó van, nagyon is, mivel erről is vitáztok, közben egyikőtök számára sem volt igazán világos."

    Nekem teljesen világos a dolog. De az alap kérdés nem ez volt, hanem az, hogy a multicore procik kihasználásához az illető szoftvernek elég több szálon futnia, vagy több process-t is létre kell hoznia.

    "Tehát a kérdés az lehet, hogy egy child-process (azaz a parent-process egy új threadje) futhat-e más CPU-n/magon, mint a parentje."

    Szerintem a child process és a thread nem ugyanaz.
  • dez #124
    Vagy, ha ezt úgy értetted, hogy "egy process új threadje(i) [child-processei] futhat(nak)-e másik CPU-n", akkor tekintsd tágytalannak a "Lehet" utáni részt.
  • dez #123
    "De nem erről volt szó szerintem"

    Jaj, hát erről is szó van, nagyon is, mivel erről is vitáztok, közben egyikőtök számára sem volt igazán világos.

    "a process-hez tartozó thread(ek) futhatnak-e másik CPU-n."

    Lehet, hogy még mindig nem világos? Mivel a kérdés az "(ek)" nélkül értelmetlen. Egy process is egy thread önmagában! Nincs olyan, hogy (sima vagy child-)process nélküli thread. Hányszor kell még leírni?

    Tehát a kérdés az lehet, hogy egy child-process (azaz a parent-process egy új threadje) futhat-e más CPU-n/magon, mint a parentje. Nos, futhat, miért ne futhatna. Mint ahogy egy procin is futhat SMT rendszerben.
További bejegyzések a fórumban...