Názory k článku KolibriOS: kolibří systém v 5 MB
-
balki (neregistrovaný)
Ja vidim vyhodu najma v tom, ze ked autori ked kodia, aspon nechlastaju. Totiz neviem si predstavit, ze by niekto opity dokazal programovat v assembleri.
Inak vidim len same nevyhody
-zavislost od instrukcnej sady x86
-nemoznost akejkolvek abstrakcie
-dokumentacia ak nejaka je, tak je urcite po rusky
-ak sa chce clovek pridat, musi sa najprv zahrat na zivy debugger.Obdivujem ich, ze to dotiahli tak daleko. Na to, ze je to v assembleri, tak je to dost komplexny system. Mne by sa z tolkeho x86-koveho assembleru vykrivili vsetky koncatiny a prekrizili oci.
-
Martin (neregistrovaný)
No třeba Roller Coaster Tycoon pro Windows je celý v assembleru a je one man show Chrise Sawyera.
Ale hlavní důvod, proč je KolibriOS nesmysl je ten, že v dnešní době je toho na internetu tolik ke zkoumání a zkoušení, že k tomuhle bych se dostal asi tak v padesátém životě. Řada věcí je totiž mnohem zajímavějších.
-
zemiak (neregistrovaný)
Stacilo by tam preportovat Chrome a je to idealne na stare notebooky/netbooky. Ala ChromeOS, pre moju zenu by to napr. stacilo.
Na starsom notebooku jej Windows startuje okolo minuty, Ubuntu porovnatelne. Keby mala system s browserom nabootovany do 10 sekund, bola by to parada. -
Serafin (neregistrovaný)
Musím říct že Kolibri OS jako projekt sleduji už nějaký ten rok nevidím v tom ani krok špatným směrem, ani absolutně bezdůvodný systém. Sice mu ještě chybí par věci do úplné krásy ale i tak stoji za to se na něj podívat blíže. A trochu lépe než někteří páni zde od stolu rovnou vyhodí soud o neužitečnosti a blbosti tohoto zařízeni.
Jádro Kolibri OS je založeno na základu Menuet OS který je už kompletně vyvíjen jen pro 64 systémy. Ve své podstatě proto není architektura omezena jen na x86.
Po stránce stability a rychlosti odezvy se mi pomalu lepší zdá jen QNX.
A upřimně, zkoušel jste někdy najít distribuci linuxu o velikosti jedné diskety která by bez problému najela docela pěkné GUI a k tomu ještě měla bezproblémové příslušenství aplikací? Já vím o jedné a o té škoda mluvit.
Rozhodně fandím tomuhle projektu už proto že není jen klon linuxu ale přináší svůj vlastní názor na řešení problému ( i když ten spíš už přinesl Menuet Os).
-
Joe Freedom (neregistrovaný)
chvílema se to dost špatně čte:
– „alespoň několik stovek a gigabajtů“ – zřejmě „několik stovek megabajtů“
– Z našeho pohledu se jedná především o svobodný operační systém a jeho zdrojové kódy jsou k dispozici pod licencí GNU GPL. – Zdrojové kódy jsou pod touto licencí nejen z našeho pohledu :)
– Na druhou stranu asi není důvod sáhnout po něčem rozšířenějším a standardizova nějším.
patrně mělo být: „…není důvod nesáhnout…“Některé věty jsou skutečně nesrozumitelné:
Navíc má problémy se zobrazováním českých stránek, což je trochu překvapivé, vzhledem k tomu, že jsem očekával, že ruští vývojáři budou problémy s nelatinkovými sadami chápat.Nechápu jak může být něco zajímavé vzhledem ke skutečnosti že autor něco očekává :)
-
petík (neregistrovaný)
Takový systém by byl strašně cool před 25 lety. Teď je jeho jediným přínosem, že tvůrci zjistí, že je to k ničemu a budou dělat něco rozumnějšího. Psát v assembleru – na ZX spectru, Atari ST, trochu i na 8086 mělo ještě smysl. Dnes má smysl optimalizovat takto jen velmi malou část kódu.
-
JS (neregistrovaný)
Jako programator v assembleru (byt na mainframu) prihodim svuj nazor. Ono je pomerne snadne napsat nejaky software, ktery je na prvni pohled rychlejsi nez systemy stavajici (a pokud ho budete psat v assembleru, pravdepodobne to tak dopadne).
Ovsem rychle narazite, pokud budete pak skutecne chtit implementovat veskerou funkcionalitu systemu, ktere se snazite kopirovat. A to bude problem i v pripade, kdy pujde o vyssi jazyk; v zasade budete kopirovat historii soucasnych systemu, ktere byly nekolikrat prepsany, casto za ucelem zvyseni vykonu.
Navic, assembler do toho vnasi dalsi problemy. Programy v nem nelze snadno refaktorovat (je to write-only jazyk), a pokud to zacnete delat, ztratite velkou cast puvodniho vykonu. Navic efektivni programy v assembleru jsou casto efektivni za cenu modularity, a pokud se tam tu modularitu pokusite dodat, zase skoncite se ztratou vykonu. V assembleru se take obtizne implementuji komplikovanejsi algoritmy, coz je zase potencialne ztrata vykonu. A to nemluvim o tom, ze dnesni prekladace jsou uz lepsi nez prumerny programator.
Vykon assembleru je navic zavisly na architekture procesoru; instrukce a zpusob psani efektivni pred 10–15 lety uz dnes efektivni neni (a to je ten lepsi pripad, kdy pouzivate instrukcni sadu pro stale zivy procesor).
Takze, abych to shrnul. Jasne, ze to startuje za 3s, protoze je to neobecne a nemodularne napsane, a neumi to tolik co soucasne desktopy. Podle me jsou to zkratka silenci, a prakticky vyznam to zadny nema (i kdyz naprosto chapu poetiku takoveho pocinu, kdyz jsem zacinal u nas ve firme, taky jsem chtel mit vsechno v mainframe assembleru).
-
j. (neregistrovaný)
Problem je aj medzi jednotlivymi generaciami procesorov rovnakej architektury – kod v asembleri napisany pre netburst procesory ma daleko k optimalnosti na nehalem nebo k8.
Kod napisany vo vyssom jazyku sa pre danu architekturu prelozi znova, sice pravdepodobne suboptimalne, ale stale v akceptovatelnej kvalite a za neporovnatelnu cenu. -
ondra.novacisko.cz (neregistrovaný)
O tom se budu hádat. Průměrný programátor nedokáže v hlavě uložit vztahy mezi části programu jedné trošku složitější šablony a to co překladač vyrobí za několik sekund, on bude navrhovat několik dní. Možná nakonec bude programátor lepší (překladač se neučí s chyb), ale za jakou cenu.
-
Bilbo (neregistrovaný)
Proto se taky v assembleru pisou jen nektere casti, predevsim na vykon pomerne kriticke casti (jadra ruznych kodeku audia a videa, sifrovaci algoritmy, …), kde zrychleni treba o 20% je celkem dost pak v praxi znat a ke kterym casto lze pouzit nejake specialni instrukce (napr. instrukce pro AES u procesoru VIA) a vyrazne tak dany kod urychlit.
-
Přesně tak, překladač nikdy nepochopí, jak to člověk myslel. Tuhle jsem potřeboval na všechny bajty v souboru provést
rol [bajt], 2
Ve „vyšším“ jazyce jsem tedy číslo bajtu převedl na 16bitový integer, vynásobil 4, udělal pár masek AND a zbytek po dělení 256…
No a kód exáče se nafoukl o 20 kB!!! O pomalosti nemluvě.
Nezpochybňuji tady ekonomickou stránku vývoje aplikací, ale kompiler si může o rychlosti kódu od člověka nechat jen zdát.
Kdybych byl autor softwaru, který si klade ambice být rychlý, volil bych hybridní přístup – horká místa v ASM a zbytek v něčem blbovzdorném. A hlavně by se mělo dát volit, jestli se budou při každém volání funkce tyto kopírovat jinam do paměti (a dokonce relokovat), nebo se to zaonačí zásobníkem, což obvykle stačí a je to daleko úspornější. -
klusacek (neregistrovaný)
Ja myslim ze zalezi na problemu. Ony prekladace to nemaji tak snadne, lecjaka informace v kodu chybi (treba vite ze nejaka funkce dostava argument vzdy nenulovy, ale kdyz ji kompilujete do knihovny tak jeste nemate vsechna jeji volani aby kompilator mohl neco takoveho odvodit – z toho duvodu se pak treba nekde uvnitr nevyoptimalizuje if). Nebo ta informace treba i ve zdrojaku je, ale slozite ji odvodit, takze se to nedela. Nebo je to neco vagniho, jako v takovych pripadech, kdy treba clovek zna typickou velikost vstupu. To pak s pomerne malou namahou muze napsat lepsi kod v ASM.
Ovsem architektura dnesnich CPU je takova ze lidem, resp. jejich dusevnimu zdravi moc nepreje. Jednak kdyz mate superskalarni CPU tak porad abyste pocital latence instrukci a jake mate vyuzit jednotek, atd. Druha vec je vyuziti cachi. Koukne na http://en.wikipedia.org/wiki/Polytope_model at vidite co treba se snazi delat gcccko. V kombinaci s http://en.wikipedia.org/wiki/Loop_tiling to muze nektere vypocty mnohonasobne zrychlit.
Jestli znate nejakeho prumerneho ASM programatora, ktery tohle dela rucne, tak ho rad taky poznam.
-
ondra.novacisko.cz (neregistrovaný)
V tomhle je nejlepší překladač o informace neochuzovat. Ideálně je templatové nebo inlinové programování. Překladač má k dispozici všechny informace, včetně obsahů funkcí, může se rozhodnout, zda kód nechá ve funkci, nebo jí inlinuje, může si přeházet registry jak potřebuje, protože vidí do funkcí, ví, které registry se budou měnit. Jediný, co mi v současných překladačích chybí je určování četností podmínek, něco jako, „tahle podmínka nastává výjimečně“. Trošku se to řeší přes výjimky, tedy test na chybu se provede jen jednou a zbytek řeší výjimka mimo hlavní scope. Ale ideální to není, protože výjmky jsou tak náročné, že se hodí spíš pro vyjádření „tahle podmínka skoro nenastává“.
Jinak vývoj v překladačích pokračuje, dopředu jde jak GCCčko, tak Microsoft Visual Studio. Optimalizuje se všude, nelze tedy program psát s tím, že dopředu vím, jak se která konstrukce přeloží. Možná dneska, za rok už to může být jinak. Tak nad tím nepřemýšlím, maximálně to řeším v časově kritických částechm a těch je málo (jsou to extrabuřty, speciality). K tomu navíc pomáhají různé profiléry, napříkla MSVC nabízí profilér podmínek … což řeší částečně to co jsem psal nahoře… podmínky se pak překládaji z ohledem na to, které větve byly pravděpodobnější. Dále je to třeba Whole Program Optimizator, který provádí optimalizace při linkování, takže ta poznámka o tom, že překladač nevidí do knihoven nemusí úplně platit. Jisté optimalizace se provádí napříč celým kódem (MSVC).
Atd, atd. Proto preferuju C/C++, ten pokrok v optimalizacích je vysoký, a troufám si tvrdit, že jakékoliv frameworky, ať už jde o Javu, nebo .NET navzdory tomu, že mezikód překládají do nativní formy, nebudou mít nikdy k dispozici tolik informací, kolik lze vytěžit přímo ze zdrojáků. A taky jsem už slyšel, že JITcompilery využívají runtime informace a optimalizují vůči něm… jenže tomu zas tolik nevěřím, protože JITC je náročná operace, kterou nelze provádět pokaždé, když se runtime informace změní.
-
> frameworky, ať už jde o Javu, nebo .NET nebudou mít nikdy k dispozici tolik informací, kolik lze vytěžit přímo ze zdrojáků
V tomhle nemate pravdu. Konkretne JVM ma k dispozici bytecode, ktery se hodne podoba puvodnimu zdrojaku, ale navic vidi i do runtime. Sun JVM dela optimalizace i na zaklade hodnot promennych, ktere prijdou zvenku, to zadny prekladac samozrejme mit nemuze.
Delal jsem si jednoduchy test, kde jsem na zaklade random hodnoty zalozil implementaci interfacu a tu jsem porad dokola volal. V C++ to trvalo asi 20× dele nez v jave. Coz je dukaz, ze JIT kompiler se muze za behu podivat co mu prislo za tridu a inlinovat volani jejich metod (a taky to dela), v c++ to samozrejme nelze pokud kompiler neodvodi jakou ma instanci. -
ondra.novacisko.cz (neregistrovaný)
No nevím, co jste dělal za test, asi by to chtělo napsat o tom článek. Nezdá se mi, že by JIT byl 20× rychlejší než nativní C++. Volání virtuální metody je „pouhý“ call podle adresy v paměti. Nic co by se nedalo proudově zpracovat (notabene, když se ta adresa po celou dobu programu nemění).
Inlinovat funkce pomůže v řádově procent, vy ale mluvíte o navýšení o 2000%. I kdyby JIT volání funkcí (vlastně virtuálně) inlinovál, například v cyklech, pak jste schopen být rychlejší dejme tomu o těch pár procent. Otázkou je, kolik času stojí vlastní spuštění JITu. Určitě lze najít speciální případ, kdy mám pět interfaců, které náhodně volám milionkrát. Ale tyhle speciální případy buď nenastávají, nebo v časově kritických částí se řeší přes šablny, čili vlastně podobně jako to dělá JIT. Akorát se to přepřeloží dopředu, pro všechny možné varianty, které mohou nastat.
-
Napsal jsem jednoduchy lowlevel test. Interface s metodami void add(), void add(int), 2 implementace, kazda do member promenne pricita nejake konstantni cislo, funkce
void count(Iface * p) { for (int i = 0; i < 1000000000; i++) p->add(); }
Zalozil jsem instance a,b tech trid a dostal jsem tyto vysledky:
nahodne vybrani a nebo b a 3× volani count s add()
JIT 0.5s
c++ 10sto same s addX(nahodna konstanta)
JIT 0.56s
c++ 13sto same s addX(i)
JIT 2.2s
c++ 13sjednou count s add()
java bez JIT 14sZaver – JIT dokaze za behu inlinovat virtualni metody, kdyz je vnitrek cyklu konstantni, tak ho dokaze i „rozbalit“. Jakykoli prekladac do nativu nema sanci, pokud si to nemuze vyhodnotit behem prekladu.
Samozrejme je to extremni pripad, ale jako reakce na „JIT nemuze…“ to myslim staci.
Pro me to znamena, ze se muzu klidne zabyvat navrhem a OOP v jave a nemusim delat nejake kompromisy v c++ aby to nebylo pomale. Kdyz navic vezmu v uvahu GC, ktery mi usetri dalsi praci a ve slozitejsich aplikacich je rychlejsi nez new/delete, tak je volba jasna :-) -
> A nezapoměl jste v C++ zapnout optimalizace? :-D
To je tak tezke tomu uverit? :-)
Delal jsem to v msvc, zkousel jsem zapinat vsechno mozne, ale myslim, ze on proste nic moc optimalizovat nemuze. Jelikoz to je virtualka, tak nanejvys chodit primo na adresu funkce, ale inlinovat nemuze. Takze volani, soucet, return, i++ mi 3e9 krat za 10s prijde dobre. Mam notas 2GHz Pent. M, takze to zhruba vychazi na 7taktu/cyklus
Kdyz tam volam to same nevirtualne, tak je to samozrejme hned.
-
ondra.novacisko.cz (neregistrovaný)
Dereferencování pointeru stojí jeden takt. Skok do podprogramu taky stojí jeden takt. Důležitý je obsah funkce. Pokud je tam typický funkční framework, tak se tam zbytečně vyplácá několik desítek taktů na vstup do funkce výstup z funkce. Proto jsou důležité optimalizace, které umí tenhle běžný funkční prolog a epligo úplně vyhodit.
Ano uznávám, že tady bude C++ hloupější, protože obě části kódu neví, s kým mají na druhé straně čest.
Na druhou stranu, jak efektivní vlastně JIT bude. Dejme tomu, že dokáže optimálně přeložit funkci se známým parametrem. Okaj, co se stane s tím kódem? Uloží se někam do cache? co když se bude zase potřebovat? Jak velká ta cache je? Co když těch rozhranní budu mít 100. Co funguje na jednom malém příkladu dobře nebude fungovat na příkladu o level výše.
Možná vás taky JIT vypekl. Zjistil, že výsledkem operace je konstanta a místo fyzického provedení kódu nahradil kód výsledkem. Vy to ale nevíte a pravděpodobně nezjistíte. Těch půl sekundy ve skutečnosti zabrala práce JITu.
Jako na každý jazyk lze najít konstrukci, kde je rychlejší, než ostatní jazyky. Zrovna na Javě můžete machrovat, pokud do cyklu přidáte jediné new. C++ určitě bude pozadu, zatímco Java poběží jako ďábel… Dokud se na to nevrhne GC. Potom už to nemusí být tak zřejmé.
Jako programátor v C++ znám cenu každé operace. V Javě si nikdy nejsem jist, jestli tahle část poběží rychle nebo pomalu. Několikrát jsem psal aplikaci, kde byly nějaké animace. Několikrát jsem řešil jejich občasné poskakování. V C++ nic takového nepozorováno.
Tím chci říct, že Java hodně těží z toho, že 80% času běží 20% kódu. Tam se JIT zřejmě dobře chytne. Ale na „velkých“ aplikací bude stále pomalejší. Vemte si třeba Eclipse. Žrout času i prostoru. Bohužel není s čím moc srovnávat, ale třeba s MSVC6, který byl ještě v C++ (MSVC Expressy jsou .NET), a rychlost nejzákladnější věcí toho editoru je úplně někde jinde.
-
Možno by tomu prospela POSIX vrstva – na začiatok niečo na spôsob cygwin, alebo preportovať dietlibc alebo uclib (alebo dokonca aj GNU libc). POSIX programy by potom stačilo „len“ prekompilovať, ale na druhej strane by s modernými aplikáciami už systém nereagoval svižne a potreboval by viac než 8MB RAM… ale v dnešnej dobe by to nestačilo, v dnešnej dobe sú hlavným problémom „alternatívnych“ OS ovládače…
-
100% Lenin (neregistrovaný)
Jejda – upřesnil by jste mi ten pojem „soudruzi“?
Nemýlím li se – pak jste tak označil programátory co se účastní tohoto projektu, čímž-to jste je, pejorativně s uvozovkami přirovnal k „soudruhům“.Pak budou „soudruhy“ i emeryčtí programátoři? A co například japonští programátoři. Co oni?
Myslím, že to je jakási podivně zvrácená logika.
A vázat čest na OSS podmínkou bůtovat z win a zápisem do NTFS? To fakt hlava nebere.
Pochopil li jsem správně Vaše sdělení, pakmoje účast v OSS ze mne udělá čestnějšího člověka?No tak tohle už s logikou nemá co dělat vůbec.
Ale aby jste nařekl, nechte tu kontakt + Vaše CV + odkazy na OSS projekty co jste vyplodil – a třeba Vás vezmeme na kontrakt.
Zrovna tu sháníme schopné prgoše i analytiky. -
V článku je, že si vybrali to nejlepší z linuxových, windowsových a dosových aplikací. To znamená, že KolibriOS je kompatibilní s Linuxem, Windowsem i DOSem? To by byla naprostá bomba, ale asi to tak nebude (to je těžké i pro Linux s Winem, a ten se nemusí omezovat na 5 MB).
Napadá mě, že ty prohlížeče (Dillo, Links, atd.) tam nedali prostě proto, že na tom systému nejdou. Není to přece Linux, DOS ani Windows.
„Co se týče podpory hardware, díky použití ovladače VESA by se mělo vše zobrazovat v podstatě na jakékoliv kartě, stejně tak s myší nebo klávesnicí by neměl být problém.“
Tohle je docela vtipné: celé slavné X.org někdy nahodit grafiku schopné není a cosi v asembleru na disketu to vždycky dokáže :) -
cleb (neregistrovaný)
No, s tou grafikou: Ano, i já bych vám napsal v assembleru program, co by používal VESA a tím pádem podporoval všechny grafické karty. Má to jediný problém: VESA pochází z roku raz dva, a tím pádem odpadají takové věci jako grafická akcelerace. X.org by určitě ve vesa módu dokázal taky běžet kdekoli. Jestli něco takového ještě vůbec obsahuje.
-
sysel (neregistrovaný)
zrovna to testuju a boot je opravdu velice rychlý. od stisku power tlacitka az na plochu kolem 6ti sekund. kdyby to mnelo poradny webovy prohlizec tak by to byla zajmava alternativa k systemum jako je expressgate a podobne. doplnit poradny webovy prohlizec s podporou modernich technologii, nejaky ten prehravac hudby a podporu wifi tak by to byla zajmava volba pro netbooky. a diky minimalni velikosti by zbylo na ssd i spoustu mista na plnohodnotny OS
