77
-
Sirkaan #77 Szerintem a Midori != Windows 8. Windows 8 egy merőben más, de nem managed rendszer lesz.
Gondoljatok csak bele egy Crysis 2 szintű játék hogy fog azon futni a jövőben. A játékfejlesztés elég erős ipar és egy ilyen managed rendszeren megpecsételődne az egész, már ami a windows-t illeti.
.NET-es fejlesztőként tudom, hogy vannak buktatói a managed rendszernek, ami nem teszi alkamassá profi szintű rendszerközeli programok futtatására, ez sajnos tény. ;)
A Vista C# graf felülete alatt is full natív DirectX támogatás van azért gyors, de Doom4-et nem írnék rá. -
#76
> adatszerkezetből adatszerkezetbe mutató adat elérési ideje korlátos, ha az elemek száma is korlátos.
Na, hat nagyjabol ezt probalom neked elmagyarazni. Ha pedig ezek az eltero adatszerkezetek egyetlen kozos grafba vannak szervezve akkor annak az egyes pontjai koze vektorok irhatok fel melyeken keresztul a leghosszabb ut determinalhato. (tovabbra is veges adatszerkezetekrol beszelunk)
> Determinisztikus esetekre PLC-t használnak
Altalanositas. Hol? Ipari kornyezetben lehet, de ennek semmi koze a temankhoz.
> RTTI működése a fordító kezében van. Minden típushoz hozzárendel egy bizonyos Typeid rekordot, melyben a típus sorszáma szerepel néhány más adat mellet. Ezt az értéket hasonlítja össze a beazonosítani kívánt típus azonosítójával.
A tipusindexeles alapveto dolog.
> sőt, léteznek advanced keresési technikák, ahol többezer adat közül max. 8-10 összehasonlításból megmondható a típusról, hogy megfelelő -e.
Ez szinten nem ujdonsag.
> Aztán a VMT-t meg jó is hogy nem írtad le. Mert amit te mondasz, az nem virtuális metódus lesz, hanem static osztály-tagfüggvény
Ha tovabbra is kenyszerszeruen egy altalad valasztott konkret hagyomanyos nyelvi fordito, netan binaris targykod architektura sajatossagait alkalmazod altalanositasban.
> mihelyst átadod az objektumod egy másik osztálynak, máris buktad az osztálytagfüggvény címét.
Es itt tovabbra sincs kiemelve, hogy mindez a hagyomanyos operacios rendszereknel megszokasbol alkalmazott redundans osztaly/objektum nyilvantartas problemaibol adodik.
Vegyel alapul egy terminalszervert ahol - mondjuk a gyakorlati pelda kedveert - 100 user van bejelentkezve es mindegyik 2 peldany Firefox-ot futtat. Az processzenkent (ures bongeszoket feltetelezve) nagyjabol 70MB, 200x70MB az 14GB-nyi lefoglalt memoria 200 redundans adattal ami 14GB helyett 70MB-tal is felirhato lenne ha van a hatterben egy kozos adatszerkezetbe szervezett egyszeru, kulturalt memoriahozzaferes-kezelesi strategia. Ha a merevlemezen rendelkezik egy futtathato binaris futtatasanak jogosultsagaval egy adott felhasznalo, akkor evidens, hogy ugyanannak a memoriaba mar korabban betoltott peldanyahoz is kell hogy jogosultsaga legyen, (!!) ha csupan az egyes felhasznalok altal folytatott tevekenyseg van kulon memoriateruleten kezelve es szeparalva. Ugyanezzel a modszerrel logikailag barmilyen eroforras megoszthato konkurrens peldanyok es felhasznalok kozott, csupan konfiguralas kerdese.
> először is [b[biztos, hogy ezzel még nem lesz típusbiztos a címtartomány kezelésed.
Mivel?
> A típusbiztosság megköveteli, hogy a forrás és a cél típusa megfeleltethető legyen egymásnak
Igen, ezt jelenti az amit irtam: "Realtime tipusazonositas."
> közös protokolokról nekem az usb jut eszembe. ott egy halom deszkriptor létezik, aminek a kitöltögetése a -közös protokol miatt- jókora erőforrást visz el.
Es mekkora eroforrast visz el ha pont-pont kozti kapcsolatokra tucatnyi protokollt hasznalunk, netan egyikbol a masikba atjarunk?
Melyik eroforrastakarekosabb? Egy jol atgondolt azonos protokollon keresztul barmilyen digitalis/digitalizalt adat tovabbitasa, vagy tucatnyi protokollt megirni, karbantartani, memoriaban tartani, egyidoben futtatni es netan egyikbol a masikba konvertalgatni?
> Na persze, és így lesz egy multitask operációs rendszerből multi threaded single task. Ami nagyjából semmit nem ér, mert ad egy nagy pofont az adatbiztonságnak, a szálbiztonságnak
He?? Tobbek kozott eppen ezt hivatott garantalni azaltal, hogy a kozos protokollok (ertsd: kozos atjarasi pontok) miatt nem kell bloatware-eket karbantartani, nem kell 25-szor ellenorizni egy felhasznalo jogosultsagat ugyanahhoz az eroforrashoz, mert minden felhasznalo tevekenysege ugyanazon a grafon megy keresztul. Ha mar az elso lepesnel elakad a masodik kriteriumot meg sem kell vizsgalni. Es ez igaz barmely szituaciora, legyen az az eroforras akar egy memoriaterulet, egy tetszoleges periferia, egy hattertaron tarolt adat, vagy mittomen egy ugyviteli szoftver altal tarolt adatbazisrekord.
> De hogy OS-t nem írtál még sem embedded sem PC környezetben az biztos.
En nem igy emlekszem.
> Tudod már miért akadt el az OO alapú Linux fejlesztése ?
Nem, de attol tartok ezuttal sem fogom megtudni. -
Jonah #75 "1. Miert nem hasznaljak RTOS-ek alatt a OO nyelveket?
Nem-determinisztikus egy-egy fuggveny lefutasa."
Visszacsatolt rendszerekben SEMMI sem determinisztikus, mert az egész egy nagy állapotgép. Determinisztikus esetekre PLC-t használnak, abban pedig biztosan nem lehet visszacsatolt hálózat, ezzel küszöbölve ki az illegális állapotokat (így nem lesz pl. a stop gombból fordulatszám növelés pl. marógépen).
"2. Miert nem determinisztikus?
Mert szinte ismetlodoen adatszerkezeteken keresztul kell elernie mutatokat melyek eleresi ideje bizonytalan. (proceduralis paradigmat kovetve is vannak ilyen esetek, de a hangsuly szinten a gyakorisagon van)"
adatszerkezetből adatszerkezetbe mutató adat elérési ideje korlátos, ha az elemek száma is korlátos. Az elérési időt csak a programozó határozza meg, legyen az akár VMT, vagy egy sima adattábla, esetleg közvetlen fügvényhívás azáltal, hogy milyen technikát alkalmaz.
"3. Melyek ezek az esetek?
Realtime tipusazonositas. (VMT-t szandekosan nem irom ide mivel futasidoben nem kell foglalkozni az osztalykonzisztenciaval ha a targykodban a metoduscimet tarolod. Ez kizarolag a forditasi idot befolyasolja)"
RTTI működése a fordító kezében van. Minden típushoz hozzárendel egy bizonyos Typeid rekordot, melyben a típus sorszáma szerepel néhány más adat mellet. Ezt az értéket hasonlítja össze a beazonosítani kívánt típus azonosítójával. Ez viszont erősen korlátos futásidejű, C++ esetében 1-2% sebességcsökkenést okoz. sőt, léteznek advanced keresési technikák, ahol többezer adat közül max. 8-10 összehasonlításból megmondható a típusról, hogy megfelelő -e. ha pedig typeid(typespecifier) futásidejét nézzük, akkor annak ideje nagyjából egy órajelciklus, mert ez kb egy define-al egyenértékű művelet. Aztán a VMT-t meg jó is hogy nem írtad le. Mert amit te mondasz, az nem virtuális metódus lesz, hanem static osztály-tagfüggvény, aminek ténylegesen címet tesz bele minden tisztességes C++ fordító az álmoskönyvek szerint is. Virtual tagokra viszont ez nem érvényes, mert ott a VMT tagot az indexe fogja azonosítani (hasonképp mint ahogy egy DLL export függvényeit is azonosítják). Ezen index adat alapján lesz a tagfüggvény megkeresve és meghívva. Mindezt általában cachelik a fordítók a sebesség optimalizálás céljából (amig az objektum-mutató azonos típusra mutat, addig nem is szoktak új VMT keresést indítani). Persze lehet ezt is tárgykódban értelmezni, de sokkal rugalmatlanabbá válik a rendszer, ráadásul a VMT kérdése itt sincs megkerülve: mihelyst átadod az objektumod egy másik osztálynak, máris buktad az osztálytagfüggvény címét. A miértre válasz az öröklődés polimorf mechanizmusa. Ha egy osztálytagföüggvényt felülírunk, akkor annak indexe a régi osztály indexét örökli, de a leszármazottban a régi osztály metódusai még léteznek - mindössze az indexük íródik át (avagy egyes fordítókban egy külön pointer mutat a szülő osztály VMT-jére!).
"4. Miert van erre szukseg?
Hogy garantaljuk a tipusbisztos cimtartomany kezelest."
először is [b[biztos[/b], hogy ezzel még nem lesz típusbiztos a címtartomány kezelésed. A típusbiztosság megköveteli, hogy a forrás és a cél típusa megfeleltethető legyen egymásnak. pl. a C++ eredetileg ilyennek indult, de aztán a C-ből átjött hozadék miatt már nem lett az.
"5. Lehetseges ezt maskent garantalni?
Igen, lehetseges, ha az adatszerkezetek kozti atjarhatosagot kozos protokollokra helyezzuk. Ha autentikus adatszerkezeteket alkalmazunk melyek kozos protokollba (pl. kozos graf adatszerkezetektol fuggetlenul) szervezhetoek akkor globalisan, a teljes rendszerben tetszoleges adat eleresehez szukseges legrosszabb eleresi ido mindig determinalhatova valik. (Az most mas kerdes, hogy sokszor nem csak a legrosszabb eset, hanem ennel joval tobb informacio is determinalhato)"
közös protokolokról nekem az usb jut eszembe. ott egy halom deszkriptor létezik, aminek a kitöltögetése a -közös protokol miatt- jókora erőforrást visz el. Vajon a közös protokolok nem visznek el erőforrásokat úgy, mint pl. egy VMT kezelés ?
Ezen felül az autentikus adatszerkezetek által garantált adatelérési idővel pedig csak óvatosan. Ha nekem olyan az adatom, aminek a kinyerése az adatszerkezetből NP teljes problémát vet fel, akkor a garantálhatóságot dobhatod a kukába.
"Egyebkent a fenti modszerrel az OO alkalmazasokat jellemzo nagy memoriahasznalat is radikalisan csokken ha elunk is a kedvezo lehetosegekkel es eleve ugy epitjuk fel az OS-t, hogy a redundans memoriahasznalatokat mersekelje. (Ugye ha a problemat gyokereiben kezeljuk, varhato hogy mas problemaktol is szabadulunk, amelyeket talan korabban altalanosan el is fogadtunk mellektermekkent es igy mar nem is foglalkoztunk veluk)"
Na persze, és így lesz egy multitask operációs rendszerből multi threaded single task. Ami nagyjából semmit nem ér, mert ad egy nagy pofont az adatbiztonságnak, a szálbiztonságnak, a "közös lónak túros a háta" elvnek, de cserébe garantáltan felvet jópár deadlock problémát, illetve egy halom olyan dolgot, amit még az ellenségemnek és t. családjának sem kívánnék.
Ebből nekem kb. az jön le, hogy lehet olvasott vagy, sokat foglalkoztál vele. De hogy OS-t nem írtál még sem embedded sem PC környezetben az biztos. Amúgy csípem a humorod, legalább értelmesen beszélgetsz:-) Tudod már miért akadt el az OO alapú Linux fejlesztése ? :-))
üdv.
-
#74
> pl. a virtuális metódusok hívásakor. ezen függvények hívása biztosan lassabb lesz. Emiatt nem is alkalmazzák embedded cuccokban RTOS-ek alatt.
Nem. Rossz a megkozelites. Csak a felszinig messz el a problema okozojanak keresesekor, majd egy felvalasszal felbe is hagyod a keresest. :-) MINDIG vezesd vegig lepesrol-lepesre visszafele a valaszt egy adott kerdesre es megtalalod az okozojat a gyokereknel (mely okozo rend szerint mashol is problemakat okoz).
Peldaul, hogyan jutunk el az aktualis problema okozojahoz:
1. Miert nem hasznaljak RTOS-ek alatt a OO nyelveket?
Nem-determinisztikus egy-egy fuggveny lefutasa.
2. Miert nem determinisztikus?
Mert szinte ismetlodoen adatszerkezeteken keresztul kell elernie mutatokat melyek eleresi ideje bizonytalan. (proceduralis paradigmat kovetve is vannak ilyen esetek, de a hangsuly szinten a gyakorisagon van)
3. Melyek ezek az esetek?
Realtime tipusazonositas. (VMT-t szandekosan nem irom ide mivel futasidoben nem kell foglalkozni az osztalykonzisztenciaval ha a targykodban a metoduscimet tarolod. Ez kizarolag a forditasi idot befolyasolja)
4. Miert van erre szukseg?
Hogy garantaljuk a tipusbisztos cimtartomany kezelest.
5. Lehetseges ezt maskent garantalni?
Igen, lehetseges, ha az adatszerkezetek kozti atjarhatosagot kozos protokollokra helyezzuk. Ha autentikus adatszerkezeteket alkalmazunk melyek kozos protokollba (pl. kozos graf adatszerkezetektol fuggetlenul) szervezhetoek akkor globalisan, a teljes rendszerben tetszoleges adat eleresehez szukseges legrosszabb eleresi ido mindig determinalhatova valik. (Az most mas kerdes, hogy sokszor nem csak a legrosszabb eset, hanem ennel joval tobb informacio is determinalhato)
Egyebkent a fenti modszerrel az OO alkalmazasokat jellemzo nagy memoriahasznalat is radikalisan csokken ha elunk is a kedvezo lehetosegekkel es eleve ugy epitjuk fel az OS-t, hogy a redundans memoriahasznalatokat mersekelje. (Ugye ha a problemat gyokereiben kezeljuk, varhato hogy mas problemaktol is szabadulunk, amelyeket talan korabban altalanosan el is fogadtunk mellektermekkent es igy mar nem is foglalkoztunk veluk) -
Jonah #73 Ez érdekes. Hogy mikor keresünk a VMT-ben ? pl. a virtuális metódusok hívásakor. ezen függvények hívása biztosan lassabb lesz. Emiatt nem is alkalmazzák embedded cuccokban RTOS-ek alatt. Inkább C és asm.
üdv.
-
#72
> mégpedig: ha egy osztályalapú OS-t veszel alapul, biztosan nem kerülheted el a VMT alkalmazását
Meg mindig elbeszelunk egymas mellett. Elismetlem megegyszer: szo sincs a VMT megszunteteserol. Meg csak utalast sem tettem erre. Es kerem, hogy ezuttal tenyleg legyen vilagos.
Az idezetemben ezert vastagitottam ki a "folyamatosan" szot, mert a kezdetektol fogva a VMT-ben valo kereses gyakorisagara (es modjaira) utalok.
Most azt, hogy hogyan oldottam meg adatszerkezeteken keresztul az ilyen jellegu problemakat azt minimum egy hetes eloadas sorozaton keresztul tudnam levezetni neked. Nem apro konstrukcios ujitasokrol van itt szo (az en esetemben), hanem teljesen uj nyelvi leiro rendszerrol, teljesen uj eroforras kezelesrol, teljesen uj generacios forditoprogramrol. Meg forraskod sincs a hagyomanyos "szoveges fajl" ertelembe veve es megcsak a fogalom, hogy "fajl" sem letezik.
Egy sokdimenzios csomoponti adatbazis van ahol a programozo/felhasznalo szemszogebol nincsen protokolbeli kulonbseg egy "konyvtar" mint gyujtoeszkoz, "fajl" mint taroloeszkoz, "port" vagy "halozat" mint I/O eszkoz, vagy akar felhasznalo, process, stb mert mindegyikuket transzparensen azonos protokollon keresztul eri el. Ami megkulonbozteti oket az a rajuk valo hivatkozas (nev, azonosito, stb).
Ez a kialakitas termeszetenel fogva olyan teljesen uj lehetosegeket hoz amelyeket ha egyuttesen alkalmazunk akkor ujra kell alkotnunk a szamitastechnikarol, informatikarol eddig tanultakat es teljesen maskent kell megkozelitenunk reszproblemakat. -
Jonah #71 tudod, ezzel van egy kis gond....
mégpedig: ha egy osztályalapú OS-t veszel alapul, biztosan nem kerülheted el a VMT alkalmazását, ami viszont minden egyes függvényhíváskor lassít egy picit. Talán többet mint egy szimpla "rep movsd". Ráadásul ez esetben is van egy probléma: nem tudod, és nem is tudhatod, hogy az adott OS fordításakor milyen címre linkelődik egy-egy metódus. Vagyis csak úgy, ha létrehozol egy -a metódusra mutató- adatterületet. aminek értékét átadod a megfelelő helyeken. Viszont még mindig van ezzel egy probléma. Ez pedig a méret, mert ha mindenkinek átadod ezt, akkor ők is tárolni fogják azt valahol, ami az erőforrások felesleges elfecsérléséhez vezet. Vagy mégjobb, átadunk egy mutatót, ahol ezen metódusok le vannak írva. És ezzel már gyak. létrehoztuk a VMT-t egy valamilyen osztályra. Aztán sebességbeli gondok is vannak.
mert pl egy
MOV ebx, [ebp+16*4]
call ebx
sokkal lassabb mint egy
call directcall
hívás. Nem beszélve az objektumpointerek kezeléséről, mert ott is akadnak gondok. emiatt az OO az embedded cuccokban nem véletlen nem kapaszkodott meg. Ha nem lenne sebességbeli gond, már régen abban írnák az oprenccerek zömét.
Apropó, tudod, hogy végül miért akadt el az OO-ban írt linux?
üdv.
-
#70
> Avagy bármiféle interfészt, esetleg absztakt osztály leszármazottat (többszörös öröklődés esetén) ?
Es most ahogy latom, hogy itt alapfogalmakban levo hianyossagok is felszinre kerultek, ugyanis a VMT lenyege - mint Virtualis Metodus Tabla - a neveben is hordozza, hogy az a virtualis metodusok cimterenek es egyeb kiegeszito adatainak gyujtemenye, nem pedig a polimorfizmus feltetele. A kettonek egyebkent semmi koze egymashoz.
A VMT-ben kizarolag a virtualis metoduskenk, netan virtualis property-kent definialt elemek tarolodnak. Normalisan megirt forditoprogramok a VMT-t letre sem hozzak olyan osztalyoknal ahol virtualis elemek nincsenek definialva. Az oka pedig amiert a VMT-re szukseg van, hogy amikor egy leszarmaztatott osztalybol letrehozott objektumon belul egy felul nem irott metodusunk egy virtualis metodusara hivatkozik, azt tudnia kell, hogy az uj osztalyban nem lett-e veletlenul felulirva az ominozus virtualis metodus. Ha igen, akkor az ososztaly metodusanak a leszarmaztatott osztaly felulirt metodusara kell hivatkoznia, hiszen pont ez a virtualis elemek lenyege.
A polimorfizmus pedig az orokolt valtozok, property-k, metodusok es egyeb osztalyokba foglalt elemekre valo hivatkozas a leszarmaztatott osztalyokbol azonos neven. Ennek pedig az egvilagon semmi koze a VMT-hez. -
#69
> Kiröhögöm a vakbelem, pont te beszélsz kultúráról, aki még az ékezetet sem ismeri és (idézlek!) "bisztos" a dolgában.... LoL
Ekezet ismerete nem gond, meglete mar annal is inkabb. Ha Magyarorszagtol tavol elsz es nem all rendelkezesedre magyar nyelvu ekezetes billentyuzet, nem ismered a magyar billentyuzetkiosztast mert talan nincs is ra szukseged a hetkoznapi eletben meg nem a kultura hianyat jelenti, csupan azt, hogy a rendelkezesre allo lehetosegeid korlatozottak.
A kozvetlen hangnemedbol feltetelezem, hogy Te egy magasan kvalifikalt szakmernok vagy aki annak idejen az egyetemen megtanulta, hogy a tanulas egyik legjobb eszkoze a kommunikacio mas szakemberekkel es annak a levezetese erzelmi kicsapongasok nelkuli pusztan muszaki alapokon. Abban is egeszen biztos vagyok, hogy az egyetemen elhangzott az is, hogy annyi tisztelettel kozelits meg masokat, mint amennyit viszont elvarsz magad is, tovabba abban is biztos vagyok, hogy ezek tettleges cafolataval - mint irasaid kulturalis minosegevel - nem hagynad, hogy masok hite meginogjon az altalanos muveltseged irant.
> Basszuskulcs, a többalakúságot hogy realizálod ?
Tovabbra is meggyozodesem, hogy egy kulturalisan erett, kutatoi figyelemmel rendelkezo kollegaval beszelgetek aki minden mondatot korultekintessel ertelmez.
Ime egy korabban elhangzott mondatom amire a fenti valaszod erkezett:
"miert van ra szukseg, hogy a VMT-ben, stb folyamatosan keresgelj?"
Itt pedig a tobbi:
...ezeknek a problemaja egyetlen gyokerben keresendo es ez nem maga az OO paradigma, hanem ezeknek a jelenlegi megvalositasaba. (adatszerkezetkeben, kodgeneralasban, eroforraskezelesben es azoknak az EGYUTTES hatekony alkalmazasaban). A hagyomanyos operacios rendszereknel erre meglehetosen korlatozott lehetosegek allnak rendelkezesre.
> Avagy bármiféle interfészt, esetleg absztakt osztály leszármazottat (többszörös öröklődés esetén) ?
Ez hol hangzott el? -
Jonah #68 "Itt is megkerdeznem: kultura?"
Kiröhögöm a vakbelem, pont te beszélsz kultúráról, aki még az ékezetet sem ismeri és (idézlek!) "bisztos" a dolgában.... LoL
"miert van ra szukseg, hogy a VMT-ben, stb folyamatosan keresgelj?"
Basszuskulcs, a többalakúságot hogy realizálod ? Avagy bármiféle interfészt, esetleg absztakt osztály leszármazottat (többszörös öröklődés esetén) ?
Te öt éve dolgozol ezen. Grat. Nyilván az ismereteid sokasága gátolt meg eddig az elkészültében :DDDDD
üdv.
-
#67
> Hmmm... ez egy baromság...
Itt is megkerdeznem: kultura?
> Tudod, hogy hogy működik egy OO nyelv natív megvalósítása?
A Singularity-hez hasonlo elven mukodo sajat operacios rendszeren es annak az OO forditojan dolgozom lassan otodik eve. Eleg valoszinu, hogy tudom mirol beszelek. (az oldalt majd befejezem ha lesz idom)
> -Akkor mesélj róla, mert az én emlékeimben a VMT tábla kezelése igencsak lassító tényező!
Eleg szamonkeroen hangzik, de azert valaszolok. Azt nem art tudni, hogy a VMT mellett sok mas minden is lassito tenyezo (pl. valos ideju tipusosszehasonlitas) melyek mindegyike valamilyen adatszerkezetben valo keresesen alapszik. Megforditanam a kerdest: miert van ra szukseg, hogy a VMT-ben, stb folyamatosan keresgelj?
En nem fogalmaznek hasonlo hangnemben, de gondolom tudod, hogy ezeknek a problemaja egyetlen gyokerben keresendo es ez nem maga az OO paradigma, hanem ezeknek a jelenlegi megvalositasaba. (adatszerkezetkeben, kodgeneralasban, eroforraskezelesben es azoknak az EGYUTTES hatekony alkalmazasaban). A hagyomanyos operacios rendszereknel erre meglehetosen korlatozott lehetosegek allnak rendelkezesre. -
turul16 #66 Nem hiszem, hogy a csak ertek szerinti atadas alatt teljes strukturak/objektuom masolasat ertenek. Ha, igen akkor felejtos a rendszer.
Kozos heap nem jelent biztonsagi problemat, mivel nem keletkezhet olyan nativ kod ami iletektelen dolgot muvelne. (Egy viszonylag kis resz foglalkozik azzal, hogy ez igy legyen, azt elvileg egyszeru ellenorizni, hogy jo -e) -
Jonah #65 "Magyarul, van egy visszamaradott tomeghiszteria ami ott kezdodik, hogy valaki egyszer azt mondta, hogy: "objektumorientalt nyelvben orultseg kernelt irni, mert a teljes rendszer lassu lesz". Az mar mas kerdes, hogy azota a hardware arak jelentosen csokkentek es a nyelvek is alkalmasak, a lenyeg a birkaoszton. Szemelyes meggyozodesem es tapasztalatom, hogy napjainkban aki ilyet allit az vagy nem tudja, hogy egy operacios rendszer hogy mukodik, vagy nem programozott meg objektumorientalt nyelvben vagy ha igen akkor az egesz emberiseg halas lenne ha abbahagyna."
Hmmm... ez egy baromság... Tudod, hogy hogy működik egy OO nyelv natív megvalósítása? -Akkor mesélj róla, mert az én emlékeimben a VMT tábla kezelése igencsak lassító tényező! (és akkor nem beszéltünk egy halom más dologról, ami ugyancsak lassít) Embedded cuccokban nem véletlen nem nyerő az OO az OS írkálásra. Max GUI, de ott sem mindig.
üdv.
-
Turdus #64 Hát én végigrágtam magam a teljes technikai doksin, de nem hiszem, hogy jobb lesz, mint bármelyik másik OS-ük... Ilyen kitételek vannak benne, pl: "nem kell figyelni a gép teljesítményére, mert az úgyis nagy", meghogy "nincs cím szerinti átadás, csak érték szerinti, mivel ez megold minden problémát". Ezenkívül minden dinamikusan foglalt memória (bármelyik taské is) ugyanabba a heap-be kerül, ennyit a biztonságról.
Ettől függetlenül azért vannak benne jó ötletek, de aligha mondanám, hogy eredetiek. Inkább csak amolyan meshup féle. Majd meglássuk. -
turul16 #63 Valoban, ha teljesen kozos laptablat hasznal minden akkor teljes TLB-t soha nem kell ervenyteleniteni.
En nem vagyok oda microkernelkert, legtobb IPC sokkal koltsegesebb, mint egy sima fuggveny hivas.
Monolitoknal nincs ilyen problema :)
Egy process, ha var valamire akkor (es tudjok, hogy 1 usecnel (joval) tobbet kene varnia) akkor is bekovetkezik a task valtas (pl. nanosleep(),(blocking) read()).
sched_yield() -el explicite is lemondhat process az idoszeleterol. -
kvp #62 "Érdekes lesz, hogy ha közvetlen a Windows 7 *előtt?* után majd megjelenik ez a Midori. :P"
Van egy meglevo platformjuk, ezt tamogatni kell valahogy. A midori egy uj kernel, ami azt jelenti, hogy fogjak a jelenlegi win32-es/win64-es alrendszert es atirjak, hogy winnt kernel helyett a midori-n fusson. Ezt barki megteheti, a wine-os csapat peldaul linux ala irta at. Innentol a gep jo resze midori alatt fut, de a programok a windows alrendszer alatt. Igy futott anno winnt4-en os/2-es program, winxp-n linux-os es linuxon win32-es. De a win16-os rendszer tamogatasat is hasonloan oldottak meg, ez az alrendszer tunik most el a vistaval.
Meg az is lehet, hogy a win7-et mar a midori kernellel hozzak ki, bar eleg nagy ervagas lenne a cegnek az osszes driver ujboli ujrairatasa a hardvergyartokkal. Valoszinubb, hogy a miniwin fele megoldast valasztjak, ahol van egy hypervisor, van egy fo kernel es van egy par kompatibilitasi kernel. A kompatibilitasi kernelekbe mehetnek a regi driver-ek es a regi win32/win64-es alkalmazasok. A fo kernelbe kerul a .net-es rendszer es programok, tovabba a gui kodjanak nagy resze es az uj driver-ek. A cpu es a memoria kezelese, tovabba a kommunikacio pedig a hypervisor feladata. -
kvp #61 "Minden procesznek van egy sajat lap tablazata (vannak kozos lapok). A hardver (MMU) kezeli ezt. Ha new/malloc (brk(), anonimous mmap()) foglalsz memoriat akkor rendszerint meg nem lesz a te processede a lap. Amikor eloszor fer hozza a process az eleteben, akkor kivetel keletkezik, es kernel neki adja azt a lapot, onantol kezdve kernel nem szol bele mit csinal vele (nincs buntetes)."
Ez a regi windows-ok mukodese volt. A midori eseteben epp az a jo, hogy egyetlen szemetgyujtos allocatator kezeli az egesz cimteret. Igy elofordulhat az is, hogy egy fizikai lapon tobb eltero folyamat adati vannak vegyesen. Maga a nyelv a biztonsagos, ezert becsuletesen soha nem fognak a folyamatok egymas adataihoz erni. Az uzenetkuldes (rendszerhivas) mindossze annyibol all, hogy az egyik folyamat atadja a kernelnek az adatterulet leirojat, amit az odaad a masiknak. Igy az adatokhoz hozza sem kellett erni, es megis sikerult a folyamatok kozotti kommunikacio.
"Task valtaskor rendszerint kiurul a TLB, kernel -> user mod valtaskor ill. vissza valtaskor nem,"
Process valtaskor. Szoftveres task valtaskor nem (pl. thread valtas). Mikrokernelek eseten a kernel jo resze is tobb masik process-ekben van, tehat neha egy rendszerhivas alatt tobb tucatszor is process-t kell valtani.
"usec alatt van egy mai processoron az ujboli kitoltese (nem kell teljesen kitolteni (Hardware vegzi), akar ns-ekrol is beszelhetnenk), kb. ms-onkent van task valtas-rol dontes (szervernel gyakran ritkabban (10ms)), (minden hoszabb I/O -ra valo varakozaskor is, ugye nincs sok ertelme azt a processt futatni ami adatok hinyaban all)."
A fenti pelda egy jatek eseten max. 100 task valtas/sec-t tesz lehetove. Igy egy jatek, ami a kernel-t hivja, ami a grafikuskartya driver-et hivja, ami a grafikat rajzolja, max. 25 hivast tudna megtenni masodpercenkent ha mikrokernelt hasznalnank. Mivel egyetlen kep kirajzolasahoz tobb mint 25 hivas kell, ezert az egesz rendszer hasznalhatatlan lenne ha a grafikus drivert kiszednenk a kernelbol es sajat process-t kapna. Ha viszont megnoveljuk a taszkvaltasok szamat, mondjuk 100-szorosara, akkor az elpazarolt ido is megno. A tlb toltesek jo resze pl. nem cache-bol jon, sot a mai x86-osok amugy is eleg lassan kezelik a process valtast. (a taszkvalto utasitasok eseten ez tobb ezer orajel/utasitas szokott lenni)
A midori nem az egyetlen jo megoldas. Ha a cpu kezelne rendesen az egy cimterbe telepitett tobb folyamatot, tehat tamogatna a fine grained protection-t, akkor is meg lehetne oldani a problemat (nagy asszociativ tabla kell csak hozza). Viszont az egyszeru es olcso, de gyors es nagy mennyisegu processzorok fele mozdul el a vilag. Arrol nem beszelve, hogy a singularity/midori eseten az os nagyobbik resze (meg a driver-ek is) teljesen platformfuggetlenek, tehat barmilyen cpu-n kepesek futni, fuggetlenul annak hardveres kepessegeitol. Vedett kod eseten akar egy lapkezeloegyseg (paging) nelkuli cpu is kepes virtualis memoriat hasznalni. (csak a szemetgyujto vezerlo fejlecebe kell tenni egy 'kilapozva xy helyre' jelzobitet) Igy egy objektum (programkod+adatok) tetszolegesen mozgathato a halozaton barmerre, mivel nincs adott hardverhez kotve. (kerulhet diszkre vagy egy tavoli gepre is) A rendszer vedelme addig tart, amig a memoriahaz kozvetlenul senki (egy programozo sem) sem ferhet hozza csak a kernel objektumkezeloje. Ha gep vedett modon kepes futtatni az alap kernelt (pl. beleegettek a bios-ba) es a par szaz soros kodban nincs biztonsagi res, akkor onnantol sokkal biztonsagosabba valik mint a jelenlegi windows-ok. -
phoenix1 #60 Azért ez érdekes, ugye nem sokára jön a Windows 7 eközben pedig még valami Midori-n is dolgoznak *gőzerővel*.
Oké, de ha a Windows 7 is valami gagyi lesz azért mert nem fektetnek bele annyi *energiát* akkor ez egyenlő a Vistával.
Sokan maradnak a Windows XP-nél és fognak is maradni. Bár azért kíváncsi vagyok mit változtatnak a Windows 7-be.
Érdekes lesz, hogy ha közvetlen a Windows 7 *előtt?* után majd megjelenik ez a Midori. :P -
uberalles #59 előbb a Visztát kéne egy kicsit kifényesíteniük és kiadni egy legalább olyan megbízható és jó operációs rendszert, mint a vLite Vista, amit pofátlanul egy horvát diáknak kellett third person megírnia...Nekem most konkrétan egy P2-300-as gépről fut 256 mega ramról , egy CDről települt 2 gigát foglal egy 5 gigás partición és tűrhető sebességű (igaz f*ssá van tvíkelve), de fut egy másik gépemen is Virtuális Gépben egy 1.8-as P4-en ahol 384 ramból 256-ot kapott a Virtuálgép és ott meg aztán jól eldöcög.. szal Viszta ide Viszta oda , sok értelme nincsen ..
Eddig egy jó Windowst sikerült írnia a Microsoftnak ez a Win2000 és ezt még egy kicsit feltuningolták így lett az XP , ezért én (is) csak 2000/XP-nek szokom hívni... Visztának nincsen igazán nagy átütő fícsöre amiért érdemes lenne vele szívni... -
turul16 #58 Csak (unsafe mentes) CLI kodot fogad rendszer. Nem tudsz gonosz (native) binarist hasznlani, ahol hibazhatsz, vagy gonosz kodot irhatsz.
Milyen kernel space - user space mapelesrol beszelsz, ILYEN NINCS.
Minden procesznek van egy sajat lap tablazata (vannak kozos lapok). A hardver (MMU) kezeli ezt.
Ha new/malloc (brk(), anonimous mmap()) foglalsz memoriat akkor rendszerint meg nem lesz a te processede a lap.
Amikor eloszor fer hozza a process az eleteben, akkor kivetel keletkezik, es kernel neki adja azt a lapot, onantol kezdve kernel nem szol bele mit csinal vele (nincs buntetes).
Task valtaskor rendszerint kiurul a TLB, kernel -> user mod valtaskor ill. vissza valtaskor nem, usec alatt van egy mai processoron az ujboli kitoltese (nem kell teljesen kitolteni (Hardware vegzi), akar ns-ekrol is beszelhetnenk), kb. ms-onkent van task valtas-rol dontes (szervernel gyakran ritkabban (10ms)), (minden hoszabb I/O -ra valo varakozaskor is, ugye nincs sok ertelme azt a processt futatni ami adatok hinyaban all). -
god25 #57 Tessék. Itt a válasz egy másik cikkre: http://www.sg.hu/cikk.php?cid=61221
Egyenértékű, mi? Hulladék MS -
kvp #56 Akkor hogy meg egy kicsit bonyolultabba tegyuk a vilagot: Hogyan lehet megoldani, hogy a singularity/midori rendszer alatt fussanak a regi win32-es programok?
A kernel, es az uj os osszes eleme egy folyamatban fut. Minden regi folyamat elindithato egy kulon dedikalt cimterben. Az illesztest egy win32 api-t emulalo dll vegzi, ami hagyomanyos modon linkelodik a regi programokhoz, viszont a modern kernel fele mar uzenetekkel kommunikal. Hasonloan mukodik a wine is. Igy lehetoseg van sebessegcsokkenes nelkul kidobni a winnt kerneleket, kompatibilitasi celbol megtartva a win16/win32/win64 api-kat. Tehat egy kis hack-elessel a singularity/midori alatt is futhat egy win32-es program. Csak a drivereket es az os alatt dolgozo programokat (pl. shell extension-oket, viruskeresoket) kell kidobni. Ha a kernel alatt ott lesz egy hypervisor, akkor az szinte 100%-ban kepes atvenni a mikrokernel alapfunkcioit (cpu es memoriakezeles), tehat maga az os mar tenyleg tisztan managed kodban futhat. A jelenleg is fejlesztes alatt allo java os-ek pl. pont igy mukodnek. (lasd: google android) -
archkoven #55 Atyaúristen!
szinte tapintható a hatalmas tudás itt a fórumon:DD -
balee66 #54 A Singularity csak egy fejlesztői projekt, kutatási célból lett kifejlesztve. Kereskedelmi operációs rendszer nem lesz belőle.
A Midori az nem a Singularity, a Midori a Singularity projekt tanulságaira építve lett kifejlesztve.
-
Ferrer #53 Úristen, ti ezen a földön éltek? XD -
kvp #52 Eloszor is szoftveres process szetvalasztas megoldhato akar basic-ben is, de barmilyen a boundary check-et nyelvi szinten tamogato nyelvnel.
Masodszor az intel cpu-k eseten a process valtas nagyon lassu, mivel sokaig tart a kernel-user valtas es minden valtaskor kiurul a tlb. Ezt ki lehet vedeni egy jobb architekturaval, pl. tagged tlb-vel es gyors syscall-okkal. Viszont ezek tamogatasa reszben hardvert igenyel, reszben nagyon sok munkat. A garbage collector-os os-ek nem szeretik a szettagolt cimtereket. Sokkal konyebb megirni oket egy nagy lapos virtualis cimterben. Lehetseges mashogy is, mivel a singularity tamogatja a szeparalt cimtereket, csak nem kotelezo a hasznalatuk. Azok a process-ek amik egy cimterbe kerulnek, sokkal konnyebben tudnak uzneteket valtani, mivel nem szukseges sem masolni, sem map-pelni a ket cimter kozott. Ez megoldja a mikrokernelek sebessegproblemajat. -
#51
"halmozza az amugy is tulterhelt buszt."
JAV: halmozza az amugy is tulterhelt buszra eso I/O keresek szamat. -
#50
1.
> Boundary check nem OO feature
Kerdes: akkor miert nem BC extension-t hasznalnak k/u-space helyett?
OO-rol mint tipusbisztos nyelvrol volt szo osztalyokba szervezett vedett metodusokkal nem pedig kiragadott bovitmenyrol proceduralis nyelvek compiler-eihez.
Ha az utobbit hasznalod kernel/user-space helyett meg mindig nem garantalt, hogy megoldottal egy lehetseges "invalid access"-t csupan csokkentetted a kockazatat, valamint az tobabbra sem garantalt, hogy egy elore definialt abstract buffer implementaciod-at ha ki akarsz egesziteni vagy fuggvenyeit "felulirni" nem fogsz olyan viselkedesebe beleavatkozni ami a szandekodon kivul szamlalok/mutatok elcsuszasat eredmenyezi. Ha OO-ban egy kulturaltan megirt es a lathatosagi jogokkal esszeruen szervezett metodusrendszerrel implementalod ilyen szoba sem johet.
> 2. Te azt emelted ki, hogy az OO eszkozok tobb memoriat hasznalnak, ami gyakran igaz...
Itt van, hogy mit emeltem ki: "Helyette viszont meg fog jelenni egy masik hatasfokvezteseg, de egy alaposan atgondolt es odafigyelessel elkeszitett objektumorientalt OS-nel a legrosszabb esetben is az 5%-ot nem haladhatja meg!
(Nehogy folytasd a multkori write-onlyt mert itt hagylak. :) )
3. Ha 4k lapokrol beszelunk, 32 bites rendszerrol. Akkor az elso eleres mondjuk 3x tovabb tart, de 1024 eleresre leosztva mar ez nem is latszik.
Ja hat mondjuk egy fuggvenynel, egy processnel es tobbnyire azonos cimtartomanyokra hivatkozva nem pedig tobbezer processznel szanaszejjel tordelve a memoriaban. Es ugye igyekezni kell ezeket elsosorban mind lokalisan a CPU-ban cachelni mert ha tartosan memoriabol olvasgatod a cache tartalmat az tovabb halmozza az amugy is tulterhelt buszt.
4. > hasonlitsd ossze sysenter/sysexit vs. call/ret utasitasok orajel ciklus szamat.
Ne komolytalankodjunk legyszi,
meg mindig a kernelspace es userspace mappelesnel tartunk terheles alatt es meg mindig ezek buszterheleserol van szo nem pedig "uresjaraton" ciklusszamlalasrol.
Es ujbol kiemelnem: nem az orajel ciklusszam szamit kiragadott fuggvenyeknel szintetikus mikrotesztekkel (mert az olyan lenne mint az univerzum modellezese ket hidrogenatommal) hanem a halmozodott I/O terheles plussz halmozodott mutexek plussz ciklusszam plussz a maradek es mindez eles kornyezetben valodi feladatoknal. -
bvalek2 #49 Hmmm. Mikor jövünk már rá végre, hogy az ilyen cégektől nem érdemes csodát várni? Majd megvesznek valamit, és eladják MS fejlesztésként, szokás szerint. Aki kicsit is belelát a nagy "szoftverfejlesztő" cégek működésébe, meg fog erősíteni benne, hogy szinte mindent külsősökkel csináltatnak. Hogy miért, azt nem tudom, valami managerlogika lehet. Egy közgázt végzett kolléga igazán felhomályosíthatna... -
turul16 #48 1.
Boundary check nem OO feature
Belepesi pontok megadasa sem OO feature
pl. az OO -elotti ADA nyelv is tudott ilyeneket.
2. Te azt emelted ki, hogy az OO eszkozok tobb memoriat hasznalnak, ami gyakran igaz,de nem minidig C++ -nal nagyon minimalis tobblet meg virtualis osztalyok hasznalatakor is. (Tudom hibrid)
3. A lapozas bunetetese minimalis, es NEM OS fuggo. Ha pl. SWAP-et akarsz hasznalni akkor eleg nehez dolgod van nelkule, es meg lassabb lenne.
Egy lap elso elerese tovabb tart, mint siman fizikalis memoriat cimezni, leven 3-4 tablazatott kell MMU-nak megnezni, aztan azt ugye cacheli az TLB -ben.
Ha 4k lapokrol beszelunk, 32 bites rendszerrol. Akkor az elso eleres mondjuk 3x tovabb tart, de 1024 eleresre leosztva mar ez nem is latszik. Boven 1% alatt lesz. Utanna meg benne lesz (egy jo darabig) a TLB -ben.
Es nem mondanam, hogy kernel memoriajat mmapolod ki, Linearaddrest kepzed Physical addressre, ez a lekepzo tabla minden processnel mas lehet.
Memoria foglalas termesztesen ido, de ez elkerulhetetlen.
4.
hasonlitsd ossze sysenter/sysexit vs. call/ret utasitasok orajel ciklus szamat. -
arrakistor #47 Úristen a topik képtől hirtelen megilyedtem hogy a Kóka már ide is beszivárgott !!
-
#46
> 1. OO nyelv nem csoda szer a gonosz ellen es nem az OO miatt sporhato ki kern/user space.
Hat miert? :)
> 2. nem feltetlen nagy egy OO pradigmat tamogato nyelven irt program memoria igenye, nem kell C#/Java -bol kiindulni.
Komplex szoftverekrol volt szo altalanossagban es OO-rol. Nem indultam ki semmilyen konkret nyelvbol es ha jobban elolvasod amit irtam, pont azt emeltem ki amit cafolni akarsz.
> Baromsag.
1. Mert?
2. Kultura?
> Ha minden aron lassunak akarod beallitani...
Itt alj! Meg mielott elkanyarodnank a lenyegrol. Nem akarok semmit beallitani semminek. Tapasztalatok megosztasarol volt szo nem pedig lelkes rajongasrol. Amiket ott leirtam azokat javareszt magam is kiprobaltam. Ha gondod van vele, akkor fejtsd ki, hogy miert.
> ... akkor, probalkozz egy mezi fuggveny hivas es egy rendszerhivas idejenk osszehasonlitasaval.
Gondolom ezt SMP multitasking mellett, kis blokkmeretnel magas CPU es I/O overhead-nel kepzelted el. Ha igen, akkor az a szazalektartomany nagyjabol valosagot mutatja. -
RecoPhile #45 Az a fickó nem kiköpött mása Bill Gatesnek? Tán a fia?! -
turul16 #44 "Az objektumorientalt nyelvek csak kesobb jelentek meg amelyek megoldast nyujthattak volna a problemaa, de a hardware - es kulonosen a memoria - arak azok tovabbra is az egekben voltak."
1. OO nyelv nem csoda szer a gonosz ellen es nem az OO miatt sporhato ki kern/user space.
2. nem feltetlen nagy egy OO pradigmat tamogato nyelven irt program memoria igenye, nem kell C#/Java -bol kiindulni.
"Az utobbiaknak a kernelspacebol mappelt memoria all a rendelkezesere.
Miert vastagitottam ki? Azert mert ez onmagaban kepes 20-40%-os hatasfokveszteseget okozni."
Baromsag.
Ha minden aron lassunak akarod beallitani a szokvanyos modelt akkor, probalkozz egy mezi fuggveny hivas es egy rendszerhivas idejenk osszehasonlitasaval. -
turul16 #43 Singularity OpenSource, hol a titkolozas ? -
nedudu #42 A rendszergarázdát ne korlátozza senki és semmi és ne egy program akarja jobban tudni hogy mit szeretne a rendszergarázda! -
kvp #41 ps: A google altal kifejlesztett android is hasonlo a technikara epul, csak ok egy java varianst hasznaltak es tobb nativ c-s kod van az os-ben, mert kernelnek linuxot hasznaltak es nem irtak hozza egy uj mikrokerneles os-t. -
kvp #40 "A rendszergarázda férjen hozzá a rendszerhez konzolokon és beállító paneleken keresztül. De ne buherálja meg file szinten... Ugyanez a programokra is legyen igaz."
Ezt lenne hivatott a hypervisor es a digitalis alairas biztositani. A problema, hogy innentol ha valaki lement egy csaladi kepet, akkor csak addig ferhet hozza amig a kepet keszito programhoz/hardverhez van ervenyes elofizetese. Ha ez lejar, akkor onnantol az ember a sajat adataihoz sem ferhet hozza. Az xbox360 mar ilyen hardvert es hypervisort hasznal. Aki szeretne, hogy miutan a gepe kap egy virust, utanna mar csak a microsoft ceges kulcsaval lehetne hozzaferni az adatokhoz, az mar az uj windows-ban is talalkozhat ezzel a fejlesztessel. Bonuszkent a kod kiszuri az illegalis programokat (pl. open source szoftverek) es a licensz nelkuli multimedias tartalmakat. (pl. letoltott filmek, mp3-ak) Biztos, hogy jo ez nekunk?
"Még rengeteg dolog van természetesen, remélem, a projekt tagjai informatikusok és először azt tervezik meg, hogy mit is akarnak megcsinálni, mielőtt elkezdik lekódolni..."
Alapvetoen regi kernel hackerekrol van szo, szoval ertenek hozza. Az alapotlet csak annyi, hogy kis binaris kernel nativ koddal es egy sajat biztonsagos programnyelv, ami nyelvi szinten biztositja, hogy ne lehessen megkerulni a szoftveres vedelmet. Igy nem kell hardveres vedelem es ezert egy nagy cimterben (process-ben) fut minden program. Ennek eredmenyekent a kommunikacio nagyon gyors a folyamatok kozott, ezert egy programot fel lehet epiteni tobb kisebb logikailag szeparalt darabbol is. Ilyen volt a xerox alto es az amigaos is. Az egyetlen ujitas az, hogy a java mintajara maga a programnyelv adja a vedelmet. (nincsennek benne mutatok es minden memoriahozzaferes szoftveresen ellenorzesre kerul) Ez a microsoft fele javaos, amit hivhatnanak akar c# os-nek vagy .net os-nek is. -
Yv@n #39 "Most akkor meg azt mondják cirka 2 év után, hogy hát akkor Vista kuka, és ugorjunk neki egy harmadik változatnak?"
Nem azt mondják.
Azt mondják, hogy miközben a kereskedelmi vonal fejlesztése zajlik a megszokott módon, és nem kell aggódni jön a Win7, addig a szürkeállományt ráirányítják egy kisérleti projectre. Egy új megközelítésre az oprendszerek terén. Nem kell aggódni, nem lesz midori a gépeken Win8 előtt :) -
JTBM #38 A rendszergarázda férjen hozzá a rendszerhez konzolokon és beállító paneleken keresztül. De ne buherálja meg file szinten... Ugyanez a programokra is legyen igaz.