Gyurkity Péter

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.

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)
  • gkalcso #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 :)
  • A1274815 #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
  • gkalcso #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.
  • A1274815 #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.
  • gkalcso #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
  • Turmoil #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...
  • A1274815 #65
    Mondjuk az álatald linkelt wikipedias cikkben éppen nem említik a CD/DVD hibás dolgot.
  • A1274815 #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.
  • gkalcso #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.
  • puppetmast3r #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