71
-
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
-
A1274815 #61 "..., 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. -
#60
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) -
A1274815 #59 "É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. -
A1274815 #58 "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. -
johnsmitheger #57 "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... -
dez #56 É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... -
A1274815 #55 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. -
A1274815 #54 "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. -
johnsmitheger #53 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. -
BlackRose #52 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. -
A1274815 #51 "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. -
Doktor Kotász #50 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. -
dez #49 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. -
dez #48 Jól párhuzamosítható fizikai-kémiai számításokat végeznek vele. -
dez #47 A helyedben inkább nem reklámoznám a Prescott jelentette környezetszennyezést... (Telj./fogyasztás...) -
Doktor Kotász #46 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. -
sgember #45 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? :) -
Zoliz #44 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. -
dez #43 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). -
Doktor Kotász #42 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. -
Doktor Kotász #41 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. -
A1274815 #40 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. -
eax #39 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. -
A1274815 #38 Bár 64 processorig az is jó. -
A1274815 #37 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. -
eax #36 FreeBSD/Solaris/Linux + erlang, pl. -
dez #35 azért legyen -
dez #34 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 [Accelerated Processing Unit].) Kár hogy még évek, mire lesz belőle valami. -
dez #33 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. :) -
sirpalee #32 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 :) ).