SG.hu·

Túl gyorsan növekszik a processzormagok száma

A Gartner kutatócég úgy véli, hogy a sokmagos felépítésű processzorok esetében túlságosan gyors ütemben duplázódik meg a magok száma, amelyet a szoftveres fejlesztések egyelőre nem tudnak követni.

A cég most közzétett részletes elemzéséből kiderül, hogy ez elsősorban azon vállalatokat és szervezeteket érinti hátrányosan, amelyek a vadonatúj szerverekbe fektetik pénzüket. Ezekben ugyanis már most túl sok processzormag található, amelyet a jelenleg használatos szoftverek (amelyeket pedig kifejezetten vállalati felhasználásra szánnak), egyszerűen nem tudnak kiaknázni.

A problémát a hardveres újítások megjelenésének üteme jelenti: napjainkban minden egyes újabb processzorgeneráció a magok megduplázását eredményezi, nagyjából minden két évben. A processzormagok, illetve a magokon végrehajtott szálak számának növelésével ugyanannyi foglalat esetében kétszer annyi processzort kapunk, mint egy generációval korábban. Egy 32 foglalattal érkező csúcskategóriás szerver esetében nyolcmagos chipek alkalmazása révén 256 magra támaszkodhatunk, két év múlva azonban a 16 magos fejlesztések révén ez a szám 512 magra ugorhat, négy év múlva pedig elérhetjük az 1024 magot (és akkor a foglalatok számát nem is módosítottuk).

A szervereken alkalmazott szoftvereknél úgynevezett "hard" és "soft" korlátokba ütközhetnek az azokat alkalmazó vállalatok. Előbbi meglehetősen jól dokumentált, hiszen a fejlesztő cég eleve úgy készíti el az adott terméket, hogy bizonyos számú magon felül egyszerűen figyelmen kívül hagyja a rendelkezésre álló további számítási kapacitást. Ezt tehát világosan feltüntetik a dokumentációban, ám a "soft" limitek esetében jóval nehezebb meghatározni a pontos számot. Az adott szoftver ugyanis tervezésénél és kialakításánál fogva egy bizonyos magszámon felül már elenyésző teljesítménybeli gyorsulást eredményez a további magok bevonásával, sőt akár az is előfordulhat, hogy csökken a hatékonyság. Az erről szóló információk azonban kizárólag saját, valós tapasztalatokra épülhetnek, amihez kitartó tesztelésre, illetve mindennapi használatra van szükség.

Az asztali gépek esetében természetesen jóval kevesebb problémát jelent a hardveres és szoftveres szféra közötti (egyre növekvő) különbség, bár az nyilvánvaló, hogy ma még meglehetősen kevés szoftver tudja kihasználni a négymagos asztali és mobil chipekben rejlő előnyöket. Nem árt azonban fejben tartani, hogy a szoftveres oldalon egyhamar nem várható a teljes átállás megvalósulása, és hogy a fejlesztések nagy része továbbra sem fogja kiaknázni a sokmagos felépítést - ezt is érdemes végiggondolni, amikor új konfigurációt állítunk össze.

Kapcsolódó cikkek és linkek

Hozzászólások

Jelentkezz be a hozzászóláshoz.

© gkalcso2009. 02. 04.. 13:37||#71
Az MFT-t nem tudta kiírni akkor, amikor hibernálásból indítottam vissza. A rendszernaplóból tudom. Egy szinkront azért elereszthetett volna elõtte.

Az logikus, hogy NMI nem a kábelben fut, mert ugye mi van, ha azzal van gond. A hibás szektoron kívül még ezek lehetnek. Gondolom a buszvezérlõ dönti el melyik súlyos, mint ahogy írtad is. Az NMI-t ezek szerint nem a PCI buszon jelzi.

Ha leírok valamit, akkor lehetõséget adok vele a beszélgetõpartner számára, hogy pontosítsa azt, ezzel ösztönöz arra, hogy utánanézzek. Az igazi flame errõl szól, kár hogy ezt mások félreértik és csak a fikázásig/személyeskedésig jutnak el.

Szerintem hagyhatjuk a témát, elég messzire elkalandoztunk :)
© A12748152009. 02. 02.. 23:26||#70
Mondjuk hibás szektor NMI-vel való jelzése, szerintem kicsit olyan, mintha ágyúval akarnánk leszedni a muslincát az égrõl. Én az NMI-t meghíbásodásokra tartanám csak, meg esetleg idõzítõnek. Meghibásodás alatt a következõket értem: elszáll a winyó elektronikája, kiég a délihídban valami kritikus dolog, lecsökkent a tápfeszültség egy határ érték alá, ram-ban az ECC helyrehozhatatlan hibát jelzett. Tárolón a sérült adatokat inkább hibakóddal jelezném, különben ennyí erõvel a hibás IP csomagot/hállózati keretet is lehetne NMI-vel jelezni.

De tovább megyek, nincs az IDE-ben NMI vezeték: IDE/ATAPI/ATA/PATA

Ha valahogy jelzik is NMI-vel, azt az IDE vezérlõnek kell okoznia, de úgy tûnik a PCI buszra sincs kivezetve. :(

PCI-bocsi, de a németen találtam kiosztást is

"Amúgy jártam már úgy, hogy xp-->hibernálás-->mobil rack ki-->kampeca. Sajna azzal nem számoltam, hogy hibernálás elõtt nem szinkronizálja ki az MFT táblát. Ezzel csak azt akarom érzékeltetni, hogy nem bolondbiztos."

Nem feltétlenül az $MFT nem került kiírásra, hanem lehet, hogy a fájl cache-ben maradt néhány módosítás, ami meg szépen, ment a hiberfil.sys-be, ha az $MFT sérül hibernáláskor, akkor nem tudna visszajönni a hibernálásból, hiszen az elején az ntldr-nek, Vistanál, a bootmgr, majd a %SystemRoot%\system32\winresume.exe-nek is tudnia kell olvasni a kötetet, ráadásul néhány esetben eldobbhatónak kell lennie a hibernálásnak.

Azonban gondolom ezt csináltad:
- használ (cuccok összegyûjtése)
- hibernál
- mobil rack ki
- elvisz
- bedúg
- másik rendszerõl ráír
- majd vissza
- bedúg
- visszajön hibernálásból és elcsesz mindent, mert kiírja a fájl cachet, ráadásúl a becachelt, $Bitmap és $MFT, $MFT_Mirr, $INDEX, $INDEX_ROOT és $LOG töredékek alapján. Na ez tényleg károsíthat.

"Ha zavar, befejezhetjük. Igazából érdekel a belsõ mûködés, és látom értesz hozzá, ezért írok."

Bocsi, de nem úgy nézett ki.

"Egy könyvbõl származik az infó, amit még fõsulin olvastam, amikor a CD meghajtókról készítettem beadandót."

Ilyenekkel óvatosan, mert néha találni nagy marhaságokat is bennük, fõleg ha fordított a könyv.

Ettõl még lehet igaz, csak hiper kódolva kell, hogy legyen: meghajtó bejelez, hogy Bad-Sector->bekódolja, hogy a vezérlõ tudja, hogy NMI-t kell jeleznie->hibakód elküld->vezérlõ veszi, átkódolja hogy az északi-híd megértse, hogy a proci NMI lábát kösse a földre. 8086 lábkiosztása
© gkalcso2009. 02. 02.. 22:19||#69
Másik smile kellett volna az MFT-s megjegyzéshez ;)

Amúgy jártam már úgy, hogy xp-->hibernálás-->mobil rack ki-->kampeca. Sajna azzal nem számoltam, hogy hibernálás elõtt nem szinkronizálja ki az MFT táblát. Ezzel csak azt akarom érzékeltetni, hogy nem bolondbiztos.

> Bus-t írnak nem storage-ot.
Mint írtam, csak az NMI miatt linkeltem. Egy könyvbõl származik az infó, amit még fõsulin olvastam, amikor a CD meghajtókról készítettem beadandót.
A buszon a rendszer kér adatot, CD/DVD/vinyó vagy kiszolgálja, vagy jelez, hogy gubi van. Ha sokáig tököl válasz nélkül, akkor jöhet a felfüggesztés.

> Így úgy tûnik inkább csak kötekedni akarsz.
Ha zavar, befejezhetjük. Igazából érdekel a belsõ mûködés, és látom értesz hozzá, ezért írok.
© A12748152009. 02. 02.. 16:00||#68
"IO Canceling: A driver tehetni meg ezt, a felettes réteg csak kérheti rá."

Pontosabban a driver támogathatja. De API-ból is indíthatod, de a kernel is elfoghatja, persze csak akkor, ha beragardtz IO van és csak az adott IO mûveletet.

"Csak nehogy az MFT kiírása közben szakítsa meg az IO-t leállítás közben."

Ad.1 CD/DVD-rõl volt szó, nem winyóról.
Ad.2 Ha beragad a HDD IO-ja tökmindegy mit ír éppen, mert úgy is mindegy lenne, de ne aggódj, nem azonnal jön az IO cancelling, a másik meg az MFT-t az NTFS.sys írja nem az Explorer
Ad.3 Ha a boot winyón van komoly IO-error, akkor a rendszer felfüggeszti a mûködését, vagy user m ódból, vagy kék halállal

"and data corruption detected on system and peripheral buses."

Bus-t írnak nem storage-ot.

Így úgy tûnik inkább csak kötekedni akarsz.
© gkalcso2009. 02. 02.. 13:45||#67
Az NMI-re tettem be a linket. Valamilyen szinten azért benne van:

> and data corruption detected on system and peripheral buses.

IO Canceling: A driver tehetni meg ezt, a felettes réteg csak kérheti rá.
Csak nehogy az MFT kiírása közben szakítsa meg az IO-t leállítás közben. :-O
© Turmoil2009. 02. 02.. 12:40||#66
Mondjuk Gartner... Akik képesek egy féléven belül kimutatni valamit, majd annak az ellentétét is, azok biztosan megbízható elemzõnek számítanak. Persze sokan kikérik a véleményüket, õk meg jól megélnek belõle.
Mint ahogy puppetmast3r is írta: virtualizáció. Bárhány mag is van, ki lehet azt használni, a tudományos számítások, szimulációk pedig mindig is jól párhuzamosíthatók voltak. Csak arra kell figyelni, hogy az egyes feladatokhoz a megfelelõ eszközt válassza ki az ember.
Vannak olyan feladatok, amikhez egy mag is elég, nyilván ehhez felesleges 4 helyett 8 magot bekötni és ha nincs elérhetõ 2, vagy 4 magos, az nem biztos, hogy hatékony. De az egy magon elérhetõ teljesítmény sem végtelen, tehát az irány mindenképp a párhuzamosítható szoftverek követése.
Végül pedig általában a hardver születik meg elõbb és a szoftverek némi késéssel követik a lehetõségeket. Legyen az grafika, tudományos számítás, adatbázis-kezelés, játék...
© A12748152009. 02. 01.. 20:37||#65
Mondjuk az álatald linkelt wikipedias cikkben éppen nem említik a CD/DVD hibás dolgot. <#wink>
© A12748152009. 02. 01.. 20:18||#64
Hát az egész rendszer még nem meredt, az viszont igaz, hogy ebben az esetben nem tudod leállítani a megmeredt programokat, mert akkor a taskmgr, vagy a kijeletkezést vezérlõ program is lemeredhet (XP/Server2k3 ig). A multi-task viszont továbbra is mûködik. Vistaban van már IO Canceling, aminek következtében legrosszabb esetben 2 perc elteltével sikeresen kilötted a megakadt processzt, vagy magától abba hagyta.
© gkalcso2009. 02. 01.. 18:50||#63
Ha hibás a CD/DVD akkor az NMI-t vált ki. Ha ennek ellenére a fájlkezelõ folytatja az olvasást, akkor mered az egész rendszer.
© puppetmast3r2009. 02. 01.. 16:19||#62
A sokmagos procikat siman ki lehet hasznalni enterprise kornyezetben :)
Mostanabn erosen a virtualizacio fele indult el a szamitastechnika.
Tobbfele megkozelitesben is (computing cloud, serverkonszolidacio)
En a geptermemben kb 10 2-4 U-s vasat valtottam ki 2 db 1U-s Sun X4150-el.
(2socket, 8mag) - 32 giga ram per node.
Ezeken speciel VmwareESX fut, de lehetne akar Microsoft HyperV is.
Jellemzoen a vallalati serverek jelentos resze alacsony loaddal uzemel, igy sokkal hatekonyabb virtualizalva futtatni oket. Igy 8 magon osztozik 4-16 gep.
Amugy meg pl a Solaris kozel linearisan skalazodik 196 prociig (lehet tovabb is de ez volt a legnagyobb amit lattam (persze ez masszivan alkalmazasfuggo, de a tipikusan HPC feladatok jol parhuzamosithatoak)
Ja es a Windowsnak is van mar olyan verzioja amit direk sokszaklas feldolgozasra terveztek...
Az viszont tevhit hogy egy mezei 2.6os linux kernel fut az alant idezett szperszamitogepeken :) Erosen patchelt, foleg a Cray-SGi vonalrol szarmazo fejlesztesek vannak benne