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

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 :)

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

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.

"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.

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

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...

Mondjuk az álatald linkelt wikipedias cikkben éppen nem említik a CD/DVD hibás dolgot. <#wink>

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.

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.

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

"..., ha nincs explorer.exe még mindig látszik az asztal és a fájlok."

Innen lemaradt, hogy hol: a dialogus ablakokban, Total Commanderben, stb.

most nem azért, de a szervereken nem virtuális gépek futnak? úgy értem, minden magra (1-2-4 magra) van szabva egy virtuális gép ahol fut egy játékszerver/egy FTP/egy honalp stb attól függ mire van optimalizálva. azért tartom ezt logikusnak, mert akkor ha pl a szerveren avn egy lekérés akkor az pl kisajátít magának 16 magot, akkor a többi alkalmazás is lelassul :S

csak flehozok egy példát a játékoknál:
van tegyük fel egy szerver 32 maggal. minden magon fut egy tökmindegy, UT3 dedikált szerver - külön virtuális gépekben. de ha a 32-õn utna egybeömlesztve a 32 alkalmazás, akkor ha az egyik belaggolna akkor a másik is?

most gémes példát hoztam fel, de sokan nem csak gétéáfórban gondolkodnak. (pl az amazondotcom sztem magasról szarik a GTA4 szar optimalizálására)

"És a swappolás nem dermeszti már le a Vistát, fõleg ha állt a vinyó, és meg kell várnia azt a 2-3 mp-et, amíg felpörög? Mert az XP-t igen..."

De az leakasztja, de az nem csak a Windows.okat érinti, bármikor amikor akarom egy tetszõleges Linux-ot is beletudok kényszeríteni és ugyan az lesz a hatása. A baj ilyenkor az, hogy az ablakkezelõ, illetve a GUI, sõt még maga a kernel egyes nem használt/ritkábban használt részei is is kikerülhet a swapbe, valamint éppen futó processek amelyek ablakot nyítottak, beleértve a desktopért felelõs shellt, meg kapják az újra rajzolás eseményt, amelyek kerzelõ rutinjai vagy a swapben vagy a winyó bineárisaiban hevernek. Könyen belátható, hogy ebbõl addig leakadás lesz, amig ezek közül legalább az egyik + GUI visszan nejön anyíra a swapbõl, hogy újra kitudja rajzoltatni magát.

"Az explorer.exe, ami ugye az egyik legfontosabb futó eleme a rendszernek, hiszen az egyik könyvtára a desktop és ezzel le is van tudva a megjelenítés."

Azért nem teljesen a shell32.dll és comdlg32.dll is besegít rendesen ebben, ha nincs explorer.exe még mindig látszik az asztal és a fájlok.

""Szóval ezt most fejtsd ki." -> Vakszerencse! Pengeélen táncolva, de sikerült neki..."

Nem! Ennek más oka volt.

"És, mint azt sokadik alkalommal megtapasztaltam nem az alkalmazást lõtte le, hanem a full desktop újraindult, minden szervízzel együtt."

Ha folyamat struktúrát állítatsz le, akkor ez az eredménye.

"Röviden nem trafálta el a helyes explorer.exe-t, amelybõl az egyik maga az ablakkezelõ volt!"

Itt valamit nagyon keversz, az ablak kezelõ a Vistaban a dwm.exe, elõtte pedig a Win32k.sys-ben volt még elõtte pedig a csrss.exe-ben volt. Sõt az Alt-TAB-ot sem az explorer.exe kezeli le.

"Szóval ezt most fejtsd ki." -> Vakszerencse! Pengeélen táncolva, de sikerült neki...

A CD-s példa csak egy volt az ezer probléma közül, amely miatt egy ablakkezelõ nem lehet oprendszer.

Köszönöm, hogy a lentiek kedvéért elvégezdted a tesztelést! Megtisztelõ.

Az explorer.exe, ami ugye az egyik legfontosabb futó eleme a rendszernek, hiszen az egyik könyvtára a desktop és ezzel le is van tudva a megjelenítés. Pár napja Vista kitalálta, hogy nem válaszol az egyik alkalmazás és bevett módszer a "pihentetés", hogy hátha egy timer megelégeli és lekezeli, de sajnos nem ez történt. Kénytelen voltam leállítani a processt. És, mint azt sokadik alkalommal megtapasztaltam nem az alkalmazást lõtte le, hanem a full desktop újraindult, minden szervízzel együtt. Legalább is ezt mutatta. Ráadásul ilyenkor pl a vírusirtó nem indul újra. Röviden nem trafálta el a helyes explorer.exe-t, amelybõl az egyik maga az ablakkezelõ volt! :) Olyan shotgun-os a lövés, bár nekem tetszik, mert statisztikailag elõbb utóbb eltalálja. Csakhát a Kill(Random(MAX_PID)) szintén mulattat :) Elveszik az ablak és az abban futó processz kapcsolata...

És a swappolás nem dermeszti már le a Vistát, fõleg ha állt a vinyó, és meg kell várnia azt a 2-3 mp-et, amíg felpörög? Mert az XP-t igen...

Sõt a kedvedért megnéztem 1 magos gépen is, hasonló körülmények között, de ott se jött be, sõt Vista alatt még az Explorer.exe is válaszképes maradt, XP alatt az azért leakadt egy kis idõre, de a többi cucc ott is akadás nélkül ment.

"A Windows nagyon ügyes "erõforráspazarló" ablakkezelõ rendszer, amelyet messzirõl sem érdekel, hogy mit akar a felhasználó... ezért nem értem, hogy miért szerepel úgy, mint mai "operációs rendszer". Sok sok évnek (évtizednek) kell eltelnie, mire profitábilis lesz az eredeti cél: az erõforrások menedzselése, nem pedig a saját célú pazarlása. Mulattat a belé vetett hit :D"

Az XServer TCP/IP overheadje meg senkit sem érdekel.

"Megjelölöm?!?! Találja ki ez a szerencsétlen! :))))"

Vista már kitalálja és valamit a Server 2k3 is tud improvizálni.

""Viszont a programnak kell tudnia, hány mag van," - Mondom a Windows ledobja magáról a LÉNYEGET! Ezt pont neki kellene csinálni! Találja ki ez a szerencsétlen! :))))"

A Windows maga tisztában van azzal, mint ahogy a Linux/Unix klonok is, de a program különbözõ szakaszai sajnos nem, ehez új nyelv kell, amely "automatzikusan" kitalálja.

"Visszatérve az eredeti témára: a szoftverek vártak a több magra és simán utol érik a vasakat, ettõl nem kell félni sztem. Hirtelen megnéztem egy Win alatt futó processzeket és van belõle 50. Nem kell bonyolult eszmefuttatás, ahhoz, hogy kiderüljön, egy proci édes kevés, ha 50-en akarnak rajta futni. Az egyetlen processzen belüli párhuzamosítás más kérdés, hiszen nem elég a párhuzamosítható részek bontása, ha minden párhuzamosított rész a memóriára vár vagy a HDD-re... Minden erõforrás szintjén analóg módon követni kell a bontást, nem feltétlenül arányosan."

Van 50 futó process, amibõl jó ha egy aktív idõnként, de általában mély álomban van mindegyik, amig valamilyen semény fel nem ébreszti. De Ubuntu alatt 127 process van.

"Még egy gyakorlati példa a Win-re és a nem létezõ multitaskingra: ha beraksz egy CD-t, borul az egész cucc :D Édesdeden eltöpreng rajta."

Vista IO Cancelling, valamint csak az Explorer szokott amúgy is lehalni a CD berakástól, a többi cucc nem.

Mikor láttál utoljára Windows-t és milyen verziót. A leírtak alapján majdnem biztos, hogy Win9x volt, bár az se hallt le igazán a CD-tõl.

Direkt beraktam egy rosszúl olvashatót, és közben ment a visszaállítás volume shadow copy-ból + Zene lejátszás + 3D alaklmazás FPS mérõvel és Wordben lazán folyamatosan vette be az a-betüket (ráfeküdtem), a zene sem akadt meg még csak be sem reccsent, sõt az FPS mérõ is stabilan tartotta a 2700 FPS-t ráadásul (mind a 4 magot használta rendesen a progi). Szóval ezt most fejtsd ki.

A Windows nagyon ügyes "erõforráspazarló" ablakkezelõ rendszer, amelyet messzirõl sem érdekel, hogy mit akar a felhasználó... ezért nem értem, hogy miért szerepel úgy, mint mai "operációs rendszer". Sok sok évnek (évtizednek) kell eltelnie, mire profitábilis lesz az eredeti cél: az erõforrások menedzselése, nem pedig a saját célú pazarlása. Mulattat a belé vetett hit :D

"Na Windowsban sem kell, elég ha az elején megjelölöd az ideális processzort számára"

Megjelölöm?!?! Találja ki ez a szerencsétlen! :))))

"Viszont a programnak kell tudnia, hány mag van," - Mondom a Windows ledobja magáról a LÉNYEGET! Ezt pont neki kellene csinálni! Találja ki ez a szerencsétlen! :))))

"Server 2k3 óta a kernel hívásban eltöltött idõ nem vonódik le a processzeknek járó idõ szeletbõl. " - Nem vonódik le, de mégis eltelik.

Nem akarom támadni a Windows ablakkezelõt, de még messze van attól, hogy komolyabb feladatokra (otthoni alkalmazás, céges alkalmazás, stb.) jó legyen olyan módon, hogy néha néha oda figyeljen a felhasználóra, ne pedig a belsõ dolgain töprengjen. Mostanában túl sok a töprengõs rész. BÁRMIT kérsz tõle. Bár vannak jelek, mert az egér már mozog, ha minden más megállni látszik is... Gondoltam rá, hogy az egész rendszert az "egér kódja után köthetnék" és máris menne tovább :)))

Visszatérve az eredeti témára: a szoftverek vártak a több magra és simán utol érik a vasakat, ettõl nem kell félni sztem. Hirtelen megnéztem egy Win alatt futó processzeket és van belõle 50. Nem kell bonyolult eszmefuttatás, ahhoz, hogy kiderüljön, egy proci édes kevés, ha 50-en akarnak rajta futni. Az egyetlen processzen belüli párhuzamosítás más kérdés, hiszen nem elég a párhuzamosítható részek bontása, ha minden párhuzamosított rész a memóriára vár vagy a HDD-re... Minden erõforrás szintjén analóg módon követni kell a bontást, nem feltétlenül arányosan.

Még egy gyakorlati példa a Win-re és a nem létezõ multitaskingra: ha beraksz egy CD-t, borul az egész cucc :D Édesdeden eltöpreng rajta. Bár a Win-ben található témák (2 db) nagyon szépek és parasztvakításra tényleg kiválóak.

Nem kell beszarni, viszonylag könnyû a magokat egymás mellé rendezni de nem olyan könnyû megírni a szoftvert. Azt Intel is a Microsoft is a Sun is és még sokan mások is gõzerõvel dolgoznak a párhuzamos fejlesztéseket mindennapivá tevõ fejlesztõkörnyezetek, könyvtárak, fordítók stb. kifejlesztésén. Az OS-ek szintén ebben az irányban fejlõdnek. Csak idõ kérdése mikor fogjuk "0 delta-v" erõfeszítésel a hagyományos fejlesztésekhez hasonlóan a párhuzamos fejlesztéseket kezelni, és akkor az párhuzamos alkalmazások ideje is meg fog érkezni.

"BeOS alatt az nem így van.
Ott a rendszer fügvényei olyanok, hogy egy program (mondjuk egy videolájátszó) minden eleme, a gombok, kapcsolók a grafikai felületen egy külön program, külön szál, amik között definiállni kell a kapcsolatokat."

Ez mind szép és jó, de ettõl még nem lesz több magra optimalizált a cucc.

"Így a programozónak nem kell azon agyalnia, hogyan csinálja a megszakításokat, mert azt az oprendszer elvégzi helyette."

Azért IRQ, NMI és DMA szintre Windowsban sem kell elmenni, az egyetlen dolog a szinkronizációs mechanizmusok, amikre mellesleg Unix és klónjainál is szükség van (Kritikus Szakasz, Szemafor, Esemény, stb.).

"A programozónak nem kell azt figyelnie, hány mag van, és hogyan települjönn át egy kód a másik magra, ha az szabad, nem kell úgy megírnia, hogy mintha két programot írna, hogy ez a kód fut le, ha egy mag van, az a kód, ha több."

Na Windowsban sem kell, elég ha az elején megjelölöd az ideális processzort számára, vagy röggzíted proceszor affinitással (bár az utobbi lasabb lehet ha egy mag valamiért sokáig nem lesz szabad). Viszont a programnak kell tudnia, hány mag van, hogy a számítás igényesebb feladatokat szét ossza. Szerintem rossz példát hoztál fel a BeOS-ban. Akkkor jó a párhuzamosítás, ha automatiokusan rájönne, hogy az adott feladatot hogyan a legcéllszerübb n db. magra megvalósítani. Megjegyzem ha programozó tudja, hogy az a rész számítás igényes és ha hajlandó egy két segéd függvény megírni, ráadásul nem is túl bonyolultak vagy hoszzúak, akkor könyen indíthat szimmetrikus szinkron és aszinkrón feladatokat úgy, hogy n. magot mindig egyenletesen kihasználják.

"Ha egy szövegszerkesztõbe a BeOS alatt belehúzod az Óra program ablakát, és elmented a dokumentumot, és azt késõbb megnyitod, akkor látni fogod az órát, ami a pontos idõt mutatva jár a dokumentumban."

OLE + DDE. Ha írsz egy olyan órát Windowsban, ami beregisztrálja magát az OLE-ban, akkor azt betudod ágyazni Wordben is és ugyan úgy járni fog.

"Tehát nem úgy van, mint a Windowsban, hogy megírták a 386-okra, és azóta fejlõdtek a processzorok, és kompatibilisnek kell lenni a régi API-val, ezért kapott néhány kiegészítést, hanem alapban úgy írták meg, hogy létezik olyan, hogy több mag vagy processzor van egy gépben."

Bocsi de ez így ahogy van hülyeség. Nerm azért, mert nem akarnák tartani a kompatibilitást vagy ilyesdmi, hanem mert a 386-os nem tudott néhány gépikódú utasítást, amit egy 486-os már igen, sõt az új gépek sokkal többet tudni, mint mondjuk egy Pentium I, de API szinten csak a függvény neveket kell tartani, a paraméterezésüket és 32 biten a 32 bites pointert (bár próbáld meg 64-biten tartani a pointert, ha 32 bies a programm), illetve 64 biten a 64 bites pointert.

Ja és az már hab a tortán, hogy NT4.0-át már nem tennél fel 386-os ra, sõt XP-ét is csak PI MMX-tõl, Vistát pedig P3-astól.

"Amíg Windowsban egy médialejátszónak izom kell ahhoz, hogy az egérrel mozgatott lejátszóban a tartalom frissüljön"

Nem csak az alaplejátszót kell venni, mellesleg Vista alatt rángathatód az alapot is ahogy csak akarod, nem proci idõt vesz el, hanem GPU rajzol.

dez:
"Na hát azt aláírom, hogy ha Windowsban több threadbem hívogatsz rendszer-függvényeket, akkor igen gyakran várakozás lesz a vége, mert maga a Windows nem olyan szépen multi-threadelt. :)"

Server 2k3 óta a kernel hívásban eltöltött idõ nem vonódik le a processzeknek járó idõ szeletbõl.

Persze, akkor fut, amikor megnyitják a dokumentumot. Arról van szó, hogy az óra program elérési útja mentõdik a dokumentumban, és amikor megnyitják a dokumentumot, akkor a program is megnyílik, és mutatja az idõt.

Amíg Windowsban egy médialejátszónak izom kell ahhoz, hogy az egérrel mozgatott lejátszóban a tartalom frissüljön, addig BeOS alatt ezt egy 486-os proci is megteszi, mert lehet olyan programot írni, ahol a megjelenített felület egy külön szálon fut.

Na hát azt aláírom, hogy ha Windowsban több threadbem hívogatsz rendszer-függvényeket, akkor igen gyakran várakozás lesz a vége, mert maga a Windows nem olyan szépen multi-threadelt. :)

Miután elmented a dokumentumot, nem megy az az óra sehova. :P Gondolom, arra gondolsz, hogy zökkenõmentes és kis OS-overheaddal járó multitaskingot és multithreadinget feltételezve bátrabban alkalmaznak real-time frissülõ dolgokat.

Jól párhuzamosítható fizikai-kémiai számításokat végeznek vele.

A helyedben inkább nem reklámoznám a Prescott jelentette környezetszennyezést... (Telj./fogyasztás...)

A Windows API függvényei mások. Lehet, hogy ott is van lehetõség, ami egy kiegészítés, de a BeOS eleve így épül fel.

Mondok még egy példát, amit nehéz elképzelnie annak, aki Windowson vagy Linuxon nõtt fel.

Ha egy szövegszerkesztõbe a BeOS alatt belehúzod az Óra program ablakát, és elmented a dokumentumot, és azt késõbb megnyitod, akkor látni fogod az órát, ami a pontos idõt mutatva jár a dokumentumban.
És ez nem azért van úgy, mert olyanra írták meg a szövegszerkesztõt, ha véletlenül valaki beledobja az órát, akkor az járjon benne, hanem ez egy teljesen normális dolog.

A BeOS-ben teljesen más az API felépítése, ezért a programok, amiket ezekre az API-ra írnak, egyszerûsíti a programozók dolgát.
Tehát nem úgy van, mint a Windowsban, hogy megírták a 386-okra, és azóta fejlõdtek a processzorok, és kompatibilisnek kell lenni a régi API-val, ezért kapott néhány kiegészítést, hanem alapban úgy írták meg, hogy létezik olyan, hogy több mag vagy processzor van egy gépben.

A Roadrunner, ami tavaly a világ legerõsebb hibrid rendszere volt, egy szuperszámítógép, 6480 AMD és 12960 Cell chip társaságában, Red Hat Enterprise Linux futott, ott vajon hogy mûködik a dolog?
Amúgy miért nem Windows ment rajta? :)

Nekem csak egymagos és mégis minden irodai alkalmazás és játék tökéletesen fut rajta. 5 éve nem is kell több nekem. Minden fejlesztés új igényeket is teremt.
Csakhogy ilyenek egyenlõre nincsenek.

Szerintem sem a Windows(ok) az emberiség legnagyszerûbb alkotása(i), de azért multithreaded a BeOS-hez hasonlóan. Tehát tudja azt, amit itt írsz, hogy egy program x threadet indíthat el, ami egy magon multitasking rendszerben fut, több magon meg SMP-ben (egyszerûen fogalmazva).

A lényege ennek az, hogy újra kellene írni az alapoktól az operációs rendszereket, és a programokat nem átigazítani hozzá, hanem minden programot újra írni az elejétõl. És akkor az történne, hogy egy program futhana akár ezer magon is, ha annyi van.

Semmi akadálya nincs a töbszálúságnak a Winen kívûl.

A BeOS rendszerszinten több magra épül fel, míg a Windows egymagos logikára épül, ahol a programozó dolga megoldani a többszálúságot egy programon belül. A programnak kell elemeznie, hogy vannak-e lehetõségek több mag kihasználására, és akkor a program másként fut. Az egyik része akkor fut, ha egy mag van, a másik része meg akkor, ha több, mintha két programot írna, aminek mindig csak a fele fut.

BeOS alatt az nem így van.
Ott a rendszer fügvényei olyanok, hogy egy program (mondjuk egy videolájátszó) minden eleme, a gombok, kapcsolók a grafikai felületen egy külön program, külön szál, amik között definiállni kell a kapcsolatokat.
Így a programozónak nem kell azon agyalnia, hogyan csinálja a megszakításokat, mert azt az oprendszer elvégzi helyette. A programozónak nem kell azt figyelnie, hány mag van, és hogyan települjönn át egy kód a másik magra, ha az szabad, nem kell úgy megírnia, hogy mintha két programot írna, hogy ez a kód fut le, ha egy mag van, az a kód, ha több.

Egyszerûen úgy írja meg a programot, hogy az több program, amik csak kommunikálnak egymással, a többit elvégzi helyette az operációs rendszer.
Ha egy mag van, akkor váltohatva hajtva végre azokat, de ha mondjuk száz, akkor egy programot simán szétdobna az oprendszer a sok magra, és gyorsul a program.

Egyébbként sokmagra nem úgy kell optimalizálni, mint sok processzorra, sok helyen óvatosabbnak kell lenni, különösen a Core 2-es Inteleknél.

Amúgy meg implementáció kérdése is, hogy menyíre skálázódik valamilyen program, valamilyen programozási nyelven megírva, valamilyen OS alatt. Win2k8 Server kódrésze fõleg az alapokat figyelembe véve Vista SP1. Win7-nél már Win32 APIra is feltornázzák az affinitás maszkot 256-ra. Ez ehy nagyon fontos és lényeges dolog lehet több magra való optimalizálásnál, illetve az ideális processzor megjelõlése, ami szerencsére már Win32 alatt is mentes az alul tervezéstõl, XP alatt ez a funkció még nem elérhetõ Server2k3-tól jött be.

Valamennyire nyilvan jo, de amikor legutobb benchmarkoltuk, az alabb emlitett OS-ek messze jobban skalazodtak sok magnal. W2k8 server akkor meg nem volt, az lehet, hogy mar jobb ezen a teren.

Bár 64 processorig az is jó.

Viszont ebben az esetben a Windows + erlang is. Persze nem win32 keresztûl, hanem Executive API-val, a processor affinitás mask silány win32-es kivitelezése miatt.

FreeBSD/Solaris/Linux + erlang, pl.

azért legyen

Egyébként az AMD Fusion projektje nem csak arról szól, hogy csak azért egy lapkán CPU és GPU, mert így olcsóbb mobil gépeket lehet kihozni, hanem a GPU general-purpose számításokra való igénybevételét is fel akarják futtatni. Ezzel (a Cellt is jellemzõ) heterogén párhuzamosítás filozófiáját követik, ami tehát azonos méretben és fogyasztáson sokkal nagyobb mat.szám.tejl.-t hoz, mint a sima CPU-mag többszörözés. (Itt persze már nem is kimondottan GPU-ról beszélhetünk, hanem general-purpose célokra optimálisabb APU-król .) Kár hogy még évek, mire lesz belõle valami.

Nagyjából jól látod. Viszont az tényleg komoly probléma lenne, ha mindenki évekre leállna a hw-vásárlással, mert becsõdölnének. :)

A DX9 -> DX10 váltást a kivételnek hoztam fel példának, hogy leültek és újraterveztek egy korosodó architektúrát az új igényeknek megfelelõen, az alapoktól kezdve.

Az más hogy még mindig nem használják ki igazán, de elég jelentõs váltás architektúrában (és erre még rájön a DX11 ami hozzáad egy halom szépséget :) ).

Miért volna baj hogy olyan hardware-t tudnak csinálni ami nem csak a jelenlegi de esetleg a késõbb megjelenõ programokhoz is jó? Én mindig is olyan gépre vágytam ami évekig megálja a helyét. Szerintem csak attól félnek hogy olyan gépeket dobnak így piacra ami akár pár évig is jó lessz és akkor nem tudnak félévente eladni olyan gépeket amik csak kicsit jobbakk az elõzõnél de a programok rendes müködéséhez mégis arra van szükség. Egyszóval szerintem csak attól félnek hogy így nem kaszának eleget.

"A teljes újratervezésnek meg nem állnak neki, bár tisztelet a kivételnek (lásd DX9 -> DX10 váltás)."
A DX9 -> DX10 -es váltást az elõtte lévõ mondatod melyik részének írtad példának, mert sajnos nemhiszem, hogy kivételhez tartozna (én legalábbis nem tudok róla, hogy bármelyik játékban lenne igazából DX10)

Szerverekkel kapcsolatban az a probléma, hogy pl. a 64 magot még hatékonyan használják ezek a programok, de pl. 512 magot már csak nagyon kevés program tud kihasználni.

Nem olyan nagyon nehéz kihasználni, technikailag. Elsõsorban egyéb okai vannak a szegényes kihasználásnak:
1. A játékok mai szerkezete alapvetõen nem sokszálas, már ami a procit illeti.
2. A grafika már ma is sokszálas, lásd a GPU-k sok-sok ALU-ját, és a pixelenként(!) 1-1 szálat jelentõ shadereket! Késõbb majd több olyan shader-kód, ami PC-n a GPU-n fut, PS3-on a Cellen futhat majd. Pl. a Geometry Shaderek, amikkel "menet közben" lehet komolyabb geometria-átszámításokat végezni. Az elkövetkezõ években fog jobban bejönni ez a technika.
3. Már rég portolták a Physix-ot a Cellre, és szép teljesítménnyel viszi, csak éppen a játékok többsége nem használja, egyátalán komolyabb fizika sincs a legtöbb mai játékban. (Itt nem néhány autó leegyszerûsítetten is elég élethû fizikájáról van szó, hanem ha az egész játékteret "áthatja" a sokelemes fizika.)
(4.-ként említhetõ az is, hogy a céget többsége minnél olcsóbban akarja letudni a kóder-kérdést...)

Elmondanám még a Cellrõl, hogy az nem egyszerûen csak egy 9 magos proci (1db 2-szálas PowerPC-féleség + 8db matematikai kóproci ). Tehát nem egyszerûen megtöbbszörözték a kis matematikai számítási teljesítményû CPU magok számát, mint ami most x86 fronton folyik! Ennek eredménye sokkal jobb mat. szám. telj./fogyasztás.

Megemlíteném még az IBM Octopiler nevû compilerét, ami szintén automatizáltan SIMD-esít és többszálúsít, csak kimondottan Cellre készült.

megelõztél..

valszeg nem hallottak még a GTA4-rõl XD

Aki nem tudja kihasználni a több magot, az ne használjon ilyen gépeket. Valószínûleg sokhelyen túlméretezik a vállalati szervereket, és ebbõl vonták le a következtetéseiket. Azzal nem számolnak, hogy a virtualizáció mégjobban el fog terjedni.
Amúgyis "64 KB memória mindenre elég".

Emberek, itt nem a ti kis desktop gépeitek vannak elõtérben amiker Crysist futtattok hanem a szerverek. Egy szerver viszont nem egyelõ egy alkalmazással. Le merem fogadni, hogy egy ESX támogat nemhogy 4 magot de jóval többet is (32), és a virtuális szerverek tuti ki tudják használni ezeket a magokat. Tehát az hogy "alig van valami" nem teljesen igaz.

Név szerint én sem ismerem õket, de vannak olyan programnyelvek, pl. tudományos számításokra, amik a párhuzamosítást automatizáltan végzik. Ezeket nem kóderek, hanem matematikusok és fizikusok használják.

Ilyenek elsõsorban Unix rendszerekre készültek (mini- és nagyszámítógépes felhasználás, de persze adott esetben kisebb munkaállomáson is elfutnak), így Linuxon is mûködnek.

Persze ez nyilvánvaló. De logikus hogy olyan területen akarnak párhuzamosítani, ahol feladat szerkezete engedi is. Ahol meg nem, ott nyilván nem tudnak (vagy nem eléggé) párhuzamosítani.