 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)
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. 
|
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)
Gigabyte EP35-DS3R, Intel Core2 Duo E4500, Kingston HyperX DDR2 800MHz 2x1GiB, BFG[Tech] GeForce 9600GT OC2 512MiB,
WesterenDigital Caviar SE16 320 GB, Corsair VX450 PSU, Coolermaster 690 ház,
|
"É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.
Intel.DH67BL.Core.i7-2600K.16GB.RAM.4TB.RAID.GTS450.2TB.Storage.Dual.EIZO.Windows.7.Ultimate.SP1
|
"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.
Munkaállomás: C64 64K RAM 5,25" floppy & Dataset
Szerver: XT8086 640K RAM 10 MB MFM HDD 12" Hercules Monitor DOS 1.0
Megy rajta a Crisys, mint az állat!
|
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.
Munkaállomás: C64 64K RAM 5,25" floppy & Dataset
Szerver: XT8086 640K RAM 10 MB MFM HDD 12" Hercules Monitor DOS 1.0
Megy rajta a Crisys, mint az állat!
|
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.
Asus P5Q Deluxe, Core2Duo E7600 3.06(4.0)Ghz, 4GB Corsair XMS(1066Mhz) RAM KIT, Sapphire Vapor-X Radeon 5750 (DX11) 1GB, FSP Zen 300W (!!!) táp, Nexus Breeze csendes ház
|
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.
Munkaállomás: C64 64K RAM 5,25" floppy & Dataset
Szerver: XT8086 640K RAM 10 MB MFM HDD 12" Hercules Monitor DOS 1.0
Megy rajta a Crisys, mint az állat!
|
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.
Munkaállomás: C64 64K RAM 5,25" floppy & Dataset
Szerver: XT8086 640K RAM 10 MB MFM HDD 12" Hercules Monitor DOS 1.0
Megy rajta a Crisys, mint az állat!
|
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.
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
|
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.
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
|
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.
|
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)
[mycom: Core2duo E4300,GeForce GT 240 (1GB),2GB DDR2,Sharp 26"(hdtv),Genius SW-HF5.1 5000]
"Az áram alatt lévő alkatrész ugyanúgy néz ki, mint a nem áram alatt lévő, csak épp a fogása más."
|
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 [utóbbiból 1db le van tiltva a PS3-ban, így összesen 8 mag aktív]). 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..
Főoldal IT/Tech Tudomány Játék Mobil Digicam Film Letöltés Apró Fotólabor WebTop Tárhely Szerverhosting Áruház
|
valszeg nem hallottak még a GTA4-ről XD
Ha nemtetszik az, hogy valamit az X oldalról linkelek, akkor nem kell flémelni, mert nem kötelező rákattintani! :P
http://hosted.filefront.com/PLaci | GTA4Gametag: PLaci1982
|
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".
Főoldal IT/Tech Tudomány Játék Mobil Digicam Film Letöltés Apró Fotólabor WebTop Tárhely Szerverhosting Áruház
|
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.
"Az internet tiszta gáz lett, amióta felfedezte magának a média, a pénzvilág, meg a sok idióta user. Ameddig a kockák voltak többségben nem volt semmi gond." - shenmuedc
|
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.
|
Azok a dolgok, ahol n-szer ugyan azt kell végrehajtani, jól párhuzamosíthatók. A probléma a sekvenciális dolgokban van, főleg ha minden egyes lépés függ az előző(ek)től.
|
Azért nem egy példa van olyan programokra amik nagyon jól skálázódnak több magon (tipikusan raytracer cuccok), és van egy halom lib is ami több ezer szálat képes párhuzamosan kezelni. Csak egy megfelelő feladatstruktúrát kellene kialakítani ami jól párhuzamosítható. Nem az a baj hogy nem tudnák megcsinálni, hanem valószínűleg egy szoftver 67-ik verziójánál tartanak, és sok olyan rész van amit a régi verziókból emeltek át, és azt foltozgatják. A teljes újratervezésnek meg nem állnak neki, bár tisztelet a kivételnek (lásd DX9 -> DX10 váltás).
|
az a problémájuk hogy azok az op. rendszerek is változó eredménnyel végzik el ugyanazt a feladatot (akár 15%)
|
Na igen, ez kb olyan szintű probléma, hogy pl a ps3ban is van 9 mag, ami elég lenne három krízis futtatásához, de ezt kihasználni, ténylegesen még senki sem képes. Persze ez a generáció végére változhat.
|
Erre én is kíváncsi lennék.
Mert mindenhol csak a Linux-flame megy, konkrétumok nélkül.
Szigorúan magánvélemény .:|:. Fuck The What .:|:. 猿 も 木 から 落ちる. .:|:. 恋は盲目.
|
Miért is? Alig támogat valami két magot is rendesen nemhogy négyet..
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el.
(Meg az, hogy a világot elárasztották a konteóhívők...)
|
"Merthogy elég régóta vannak olyan oprendszerek + programnyelvek amik lehetőséget adnak a többmagosra irt kódok hatékony fejlesztéséhez."
Itt konkrétan mire gondolsz? Mert a Linux + C/C++ sem alkalmasabb rá, illetve bármely Unix klon + C/C++-ra ez igaz. Tényleg kíváncsi vagyok.
|
OS osztja szét magokra a feladatot, az csak akkor gyorsít, ha több szálas a feladat vagy több nagy CPU igényű feladatot futtatsz. Hiába váltogat a magok között az OS (megjegyzem, ezt utoljára az XP csinálta, hogy automatikusan váltogat a magok között, Vista inkább a nagyobb sebesség érdekében nem vált magot, ha lehet, az adott feladat alatt).
|
Hahó, tisztelt Gartner, nem csak a winfos létezik! Mert az valóban nem való ilyesmire.....
Merthogy elég régóta vannak olyan oprendszerek + programnyelvek amik lehetőséget adnak a többmagosra irt kódok hatékony fejlesztéséhez.
|
Szerintem is annak kéne, pedig mennyire nem tudja, lásd játékok többsége.
Egyébként a proci egy magon belül próbálkozik pipekre bontani a szálakat, több kevesebb sikerrel. Az AMD-nél volt is egy terv (1 éve), hogy egy hid segítségével a több mag egynek látszódjon, és ne csak látszodjon hanem egy magként is működjön. Nem tudom, hogy hol tart ez a dolog, de lehet hagyták a fenébe, mert a marketing most a magok számának növelésében látja az üzleti sikert.
|
ez a második mondatodban volt...
oly világosan mutattál meg mindent, hogy ha nem állna ezzel szemben Aristoteles szövege, mely világosan azt mondja, hogy az idegek kiindulópontja a szív, kénytelen lennék elismerni, hogy igazad van
|
...bocs, már az első mondatban hiba: az _OS_ osztja a magokat a folyamatok között
A flipflop és a visszhang összehasonlítása:
flipflop: eszem-iszom-eszem-iszom-eszem-iszom-eszem-iszom
visszhang: eszem-iszom-iszom-iszom-iszom-iszom-iszom-iszom
|
Asztali témában ez egyáltalán nem érdekes. Itt úgyis a proci osztja a magokat a folyamatok között, az alkalmazásnak erről semmit sem kell tudnia.
Szerver oldalon picit tényleg más a helyzet, mert itt nem fut annyi szál egyszerre. Itt tényleg az alkalmazásnak kellene tudni kihasználni a sok magot.
Nekem viszont nincs szerverem, és egy önző nemtörődöm állat (hihi) vagyok, szóval kitérdeke'?
A flipflop és a visszhang összehasonlítása:
flipflop: eszem-iszom-eszem-iszom-eszem-iszom-eszem-iszom
visszhang: eszem-iszom-iszom-iszom-iszom-iszom-iszom-iszom
|
Még mindig jobb, ha valamerre fejlődik a hardver, minthogy toporogna, hogy bevárja a szoftvert.
|
Na jó, vannak programok, amik kihasználják a több/sok magot, de 1. desktop alkalmazások közül kevés program használja ki akár csak ezt a néhány magot, legtöbb a 2-t sem; 2. szerver alkalmazások közül is kevés használja ki a többszáz magot, vagy akár csak a több tucatot. Adott esetben nem is lehetséges annyifelé bontani a feladatot, és/vagy az ezzel járó pluszadminitrszáció több erőforrást használ, mint maga a feladatvégrehajtás. (Ezért pl. a szuperszámítógépek sem jók mindenre.)
|
"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."
Ez valami vicc ?
|
A programok többségének jó lenne...
Mindenesetre jobb lenne jövőre egy 6-7 GHz-es 4-magos, mint egy olyan 8-magos, ami ugyanúgy ~3 GHz-en jár, mint a mostaniak...
|
Nekem is sok az az 53 m2 amiben lakok, mert nem szaladgálok álló nap föl-alá a lakásban. Mindazonáltal nem szívesen korlátoznám le az életteremet mondjuk 16 m2-re. Jó az, ha a hardver fejlődik. A szoftver most éppen nem követi a fejlődését, de eljön az idő (nem is olyan sokára), amikor már a hardvert nem lehet tovább bonyolítani/miniatürizálni. Majd szép lassan a szoftver is felzárkózik. Ha lesz rá igény miért ne?
A szenvedés az az, amitől az ember jobbá válik. Csak túl kell élni.
|
Persze használjunk egy magot 6-7GHZ-n sokkal jobb lenne .
techgarazs.com ingyendomain.tk
BME
|
Lassan több mag lesz, mint ahány fogam van...
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el.
(Meg az, hogy a világot elárasztották a konteóhívők...)
|
|
Nyomtatás
Elküldés e-mailben
Túl gyorsan növekszik a processzormagok száma
Western Digital: 2 TB-os merevlemez
35 millió netbook kelhet el idén
Új chipek az Intel és az AMD háza táján
Idén jönnek a Seagate SSD-meghajtói
Olcsóbb és gyorsabb lesz a DDR3 idén
Intel: idén jön a 320 GB-os SSD
