Názory k článku
Bude příští kernel napsaný v Go?
-
lol2 (neregistrovaný)
svet je uz teraz ovela dalej https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg - v js sa da napisat cela VM :)
-
j (neregistrovaný)
Serioznich vedeckych praci ktere se ukazaly byti totalnim blabolem sem uz videl stovky. A tahle k nim naprosto zjevne patri.
Kolik ze radku kodu ma kernel? Joaha, o par radu vic (cca 20M) , takze celkovej rozdil vykonu ... bude taky o par radu jinde.
Apropos, kdykoli je v nazvu clanku na konci otaznik, odpoved zcela vzdy zni NE!
-
Filip JirsákStříbrný podporovatelKolik ze radku kodu ma kernel? Joaha, o par radu vic (cca 20M) , takze celkovej rozdil vykonu ... bude taky o par radu jinde.
Vy jste génius. Takže když kód na 30 000 řádků je o 10 % pomalejší než ekvivalentní kód v C, kód na 60 000 řádků bude pomalejší o 20 %? Toho přece můžete využít opačně – kód rozdělíte do menších programů, a ty budete spouštět postupně po sobě. Třeba ho rozdělíte na 2 programy po 15 000 řádků, takže ty programy budou pomalejší jen o 5 % – a když je pustíte po sobě, udělají stejnou práci, jako ten 30000řádkový, ale se snížením výkonu jenom 5 %. Tuhle teorii byste měl rozvinout, možná dostatečně krátké programy v Go budou dokonce výkonnější, než optimalizovaný assembler. -
Ja by som predpoklad, ze vacsi software beziaci nad nejakym runtimom, ktory implementuje GC a nejaky netrivialny memory model bude oproti plne nativnemu kodu bez runtimu a s poctivym memory managementom pomalsi o viac % nez mensi hned tak nezatracoval. Predsalen skalovanie toho runtimu tak trocha z principu nemoze byt konstantne. GC ma nejaku reziu a ta obvykle narasta s poctom blokov. Ak sa budeme bavit o stromoch, tak niekde okolo logaritmickej zlozitosti pri hash tabulkach to bude lepsie, ale zasa treba zaplatit ich menezment.
Dalsia vec, ktoru treba zohladnit je, ze Linuxovy kernel je pomerne priamociary a riesi problemy od lesa. Velmi sa nesere so stabilnymi API, vrstvenim, izolaciou a pod. V podstate je to jedna velka guca kodu, ktora si stastne bezi na jednej hromade. To moze byt celkom lahko jeho najvacsia performance vyhoda. Aspon onoho casu (niekedy za cias OS X 10.5) niekto spustal performance testy na Linuxe a OS X a vysledok bol ten, ze mikrokernelova architektura Darwina bola totalne konkurencieneschopna, ak doslo na silne (silne = zhruba 4 a viac paralelnych pristupov k jednemu stroju) paralelny pristup k zdrojom. Nebol by som prekvapeny, keby zhruba podobny vysledok podali aj Windowsy. Tam ale zasa bude skreslenie v tom, ze fork() nie je na Windowse zrovna efektivna cesta ako vytvorit proces, takze treba spravit hodne specificky test, ktory odizoluje tieto architektonicke rozdiely a niektoru z platforiem umelo neznevyhodni pouzitim neefektivneho algoritmu.
Ale nezameraval by som sa ani tak na ten vykon. Ved dnes si ludia pokojne pustaju systemy vo virtualkach, kde tych 10-15% stratia v pohode a nestazuju si. Skor je zaujimave zhodnotit pros & cons. Pre mna je jednoznacne con ak jazyk, resp. jeho standardna kniznica nie je zmrazena a sama o sebe ma celkom slusny pocet CVE. To je take... take korporatne. Ako vyhodu by som od jazyka cakal viac nez GC. Cakal by som napriklad aj ciastocne alebo uplne riesenie problemov s paralelizmov. A tu to ma mna sukromne lepsie naslapnute Rust. Go vnimam ako vec, ktora je si uz svojich 15 minut slavy vybrala a nie a nie zdochnut.
-
Filip JirsákStříbrný podporovatel
Mezi „neškáluje konstantně“ a „řádově větší program bude řádově pomalejší“ je ještě velmi široký prostor. Navíc ten příklad s GC není dobře zvolený, protože i program bez GC má typicky režii se správou paměti – i pro takový program je potřeba udržovat mapu zaplnění paměti (ať už jí pro větší bloky udržuje jádro, nebo pro menší bloky implementace
malloc()). Režie GC bude oprotimalloc()větší při zjišťování objektů, které je potřeba uvolnit, a to závisí na složitosti struktury objektů, která přímo nesouvisí s počtem řádků kódu.Myslím, že v případě popsaném ve zprávičce se zdaleka neřeší jen GC. Automatické řešení paralelizace je podle mne stále ještě moc nákladné na výkon. Navíc v případě OS je to hodně závislé na tom, jak se např. chovají různé periferie, takže by se v podstatě dnešní kód OS musel přenést tam, kde by se řešil ten paralelizmus.
-
jouda (neregistrovaný)
Tak nevím, jestli zjištění že "v jazyce který neumožňuje memory related bugy je méně memory related bugů" implikuje "kernel bude bezpečnější", na nějaké závěry by to chtělo několik let být v focusu bug hunterů, pak teprve by porovnání dávalo nějaký smysl.
Cena 10% výkonu dolů taky není zanedbatelná, i když ve stínu Spectre/Meltdown je to drobnost.Ostatně php je taky memory safe jazyk, a že by byly v něm psané weby nějak extra bezpečné se říct nedá.
-
Tom (neregistrovaný)
ale o to jde, ne? Zrušit celou kategorii bugů dříve než se odhalí.
Bezpečnostní problémy v PHP nepramení z PHP, ale z jeho použití, buď přes ně protlačím data, která se pak spustí až na prohlížeči, tj. s PHP to nemá moc společného. Nebo nechám zapsat soubor, který zase s PHP spustím, opět to není tak moc zranitelnost samotného jazyka. Tyhle chyby se ale dají velice efektivně odchytit přes review, race condition, memory related bugy se už daleko hůře ručně objevují a spousta objevených CVE v kernelu z poslední dobu je z fuzzy testování.
-
jouda (neregistrovaný)
Tak moment, to že dám do cookie "group=admin", případně (např.) chybná podmínka takže se do procesu namapuje R/W celá dostupná RAMka je problém použití jazyka, ale a[-1]=0 je zranitelnost jazyka?
Pardon, to mi připadá jako hraní se slovíčky, aby preferované řešení vypadlo jako lepší (neříkám že není, jen mě trochu vadí hypování a co je staré to je špatné), ale ve finále je výsledek stejný, dojde patrně ke kompromitaci.Navíc tu jsou sociální faktory, třeba nižší laťka pro schopnosti programátora v jazyce, který za něj chodí i na záchod, se může dost negativně projevit na kvalitě výsledného kódu, takže sice jsme se vesele zbavili celé kategorie chyb, ale bezpečnost to nějak zvlášť neposílilo.
BTW: Zkusil někdo vymyslet třeba side channel timing útok na garbage collector, jaká data tak můžou utéct? (tedy něco co ve standardním kernelu není - takže potenciální pole neorané a pravděpodobně dosud neznámá nová kategorie bugů).
Nemyslím že by analýza podobných nechtěných následků byla triviální. -
j (neregistrovaný)
"Nemyslím že by analýza podobných nechtěných následků byla triviální."
Naopak, cim vic takovych samoseroucich se veci v kodu mas, tim hur se potencielni chyby odhalujou, protoze ve finale vlastne nikdo nevi, co to dela a kdy to dela a proc to dela, takze kdyz pak nekdo na neco narazi ...Bejvaly casy, kdys moh prikaz po prikazu prelozit danou vec do asm, a vedel si, ze vicemene totez vypadne i z kompilatoru. Takze si vedel co to ve finale bude delat. Dneska mas kompilator kterej se snazi myslet za tebe, mas cpu kterej se snazi myslet za tebe, maz jazyky ktery za tebe chodej na ten hazlik, takze vysledek je, ze uz vlastne nikdo nevi, co to bude ve finale delat.
-
Grammar nazi (neregistrovaný)
Tak hlavně aby na ten jazyk byla dostupná dokumentace na úrovni což se moc o PHP říct nedá..
Jeden příklad za všechny.
Tenkrát jsem potřeboval zapsat data do souboru po ukončení načítání dané stránky.
Ze začátku to bylo lehký. Použil jsem "register_shutdown_function" a myslel jsem, že je hotovo.
No a v dokumentaci se už třeba nikde nepíše, že se po zavolání fce mění aktuální cesta na nějaký základní s*it..Opravdu krásně ztracených 15 minut něčím co by mohlo být v dokumentaci..
PS: Pro ty z Vás, kteří neumí číst a myslí si, že haním PHP, tak omyl, jen jeho dokumentaci...
-
null null (neregistrovaný)
@Grammar nazi
39 livejournal.com/~sinde1/ 12 years ago
If you want to do something with files in function, that registered in register_shutdown_function(), use ABSOLUTE paths to files instead of relative. Because when script processing is complete current working directory chages to ServerRoot (see httpd.conf)
[http://php.net/manual/en/function.register-shutdown-function.php, 2018]
Naopak bych řekl, že jsem viděl spoustu horších dokumentací.
-
j (neregistrovaný)
Jenze ono to neni 10%. Kdyz implementujes veskerou funcionalitu kterou ma kernel, tak to bude rozdil v nasobcich. Viz vejs, i kdybys to prepocital jen na rozsah kodu, tak to mas rekneme 100k vs 20M => 200x ... (neda se to samo takhle uplne vynasobit, ale ten rozdil bude naprostro tristni).
A jak sam pises, budou v tom jiny chyby, prevazne jeste mnohem zaludnejsi.
-
j (neregistrovaný)
A ty drivery nebezej a nic nedelaj ... takhle to vidis?
Mistni squadra negramotnych blbu totiz nezvlada ani scitat, a ten vykon se nebude scitat ale nasobit ... protoze on bude o tech 10% poamelejsi taky... trebas filesystem, takze ... se na nej bude o to dyl cekat. O 10% pomalejsi bude sitovani ... atd atd atd atd.
-
Ondra Satai NekolaZlatý podporovatelPřesně tak. Ty drivery v drtivé většině nebeží a nic nedělají. Protože drtivou většinu HW v počítači nemáš.
Neztrapňuj se.
-
j (neregistrovaný)
Narozdil od blbu jako ses ty nekola, vsichni svepraveni vedi, ze vkazdym PC bezi nejmin desitky driveru. A kupodivu i uberbeblb vi, ze ten pocitac taky muze mit pripojenych destet ruznych fs ... couz sou ...o svata prostoto ... zase drivery ze? A pak mu pobezi taky sit, protoze provozovat neco bez site to sem nevidel uz hodne dlouho ... a to jsou .. dalsi desitky tisic radku kodu ze? A takhle muzem pokracovat dal a dal ze? Kdyz se neco pripoji do USB ... oh shit, dalsi driver ... kterej kupodivu ... bezi i kdyz tam nic pripojenyho neni, protoze ... co kdyby ze?
Ale blbove samo nemuzou vedet, ze i jen driver nactenej do pameti a "nic nedelajici" ovlivnuje vykon, protoze dalsi desitky tisic radku kodu se nactou proste proto, ze to tak je bydefault, aby vetsinou vetsina veci fungovala. A fakt chci videt jak kazdej jeden admin kazdyho distra kompiluje vlastni kernel proto, aby tyhle veci vyhazel a jak travi hodiny a hodiny casu zkoumanim, jestli tohle jeste vyhodit muze nebo nemuze.
A mimochodem, soudruzi z M$ zkusili napsat widle v C# ... a cely to zahodili protoze to bylo zcela nepouzitelne ... pomaly!
-
unicode (neregistrovaný)
To je pravda, psal jsem to unáhleně, ale to porovnání v tom článku je hodně povrchní:
1. There are a number of kernels in Rust, but none were written with the goal of comparing with C as an implementation language.
2. There is no consensus about whether a systems programming language should have automatic garbage-collection. For example, Rust is partially motivated by the idea that garbage collection cannot be made efficient; instead, the Rust compiler analyzes the program to partially automate freeing of memory. This approach can make sharing data among multiple threads or closures awkward.
3. A language without a compiler as good as Go’s, or whose design was more removed from the underlying machine, might perform less well. On the other hand, a language such as Rust that avoids garbage collection might provide higher performance as well as safety, though perhaps at some cost in programmability for threaded code.
Ať si každý udělá vlastní závěr.
-
Při vší úctě, myslím, že tady na rootu není nikdo, kdo by měl třeba jen desetinové znalosti z pohledu vývojáře kernelu, jako ti, kdo tu práci psali (a to čtenářům poměrně značně fandím). Takže závěr si jisto jistě může udělat každý sám, ale otázkou zůstává, co bude obnášet.
Jedna neumím posoudit, ale mohl byste rozvést, jaký problém máte s dvojkou a trojkou?
-
unicode (neregistrovaný)
Ty body samotné jsou jen výcuc z toho paperu, kde zmiňují Rust. Já jsem to právě nechtěl nějak extrémně analyzovat tak proto mám radši, když si závěr udělá každý sám, přečíst si to celé neuškodí. Na můj vkus ten paper obsahuje poměrně silné tvrzení typu "A language without a compiler as good as Go’s", atd...
-
Ano, vím že to jsou citace.
Zkusme se podívat na dvojku. První věta (There is no consensus about whether a systems programming language should have automatic garbage-collection.) je konstatování. Vzhledem k tomu, že existují systémové jazyky s GC i bez, tak se asi shodneme, že popisuje realitu. Následující věta (For example, Rust is partially motivated by the idea that garbage collection cannot be made efficient; instead, the Rust compiler analyzes the program to partially automate freeing of memory.) podle mne přesně vystihuje jeden z přístupů Rustu. A poslední věta (This approach can make sharing data among multiple threads or closures awkward.) jen konstatuje, že v případě kdy automatická detekce uvolnění paměti selže, dostáváme se do stejného problému jako v jazyce C a jeho řešení je "neobratné" (na rozdíl od automatického uvolnění paměti v jazycích s GC).
U trojky vás pravděpodně "namíchla" první věta :). Na druhou stranu, pokud uvážíme, že rozdíl ve výkonosti proti C je cca 5-15 %, přičemž velkou část spotřebují věci jako jiné volání funkcí (časově náročnější), kontroly mezí a GC, tak ten kompilátor asi opravdu není tak špatný. Pak už jen konstatují, že u jazyků, které jsou vzdáleny více od HW (třeba vše nad JVM) mohou být výsledky horší a naopak třeba u Rustu lepší. Poslední věta jen opakuje, že to zrychlení u Rustu je za cenu složitější práce programátora při využití více vláken.
-
nbusr123 (neregistrovaný)
Přiznám že jsem neměl čas studii číst, ale trochu bych se pozastavil nad těmi procenty. Je myšleno o 10% větší režie jádra nebo o 10% horší aplikační výkon. Pokud to první, je to super, pokud to druhé tak to zdaleka tak super není, protože to velmi snadno může znamenat, že režie jádra vzrostla klidně o 1000%...
-
Nevím, co přesně myslíte režií jádra, ale pravděpodobně to, co je ve studii nazýváno low level testy. Tam vyšly rozdíly 5 a 15 %. Porovnávaly se identické "cesty", ta režie padá čistě na rozdíly v překladu obou jazyků (způsob volání funkcí, kontrola indexu polí, alokace a uvolňování GC). V tabulce je tam přímo rozpadnuto procentuální podíl na jednotlivé skupiny.
-
null null (neregistrovaný)
@ivossz
"Tato práce do určité míry vyvrací zažité stereotypy o nezbytnosti použití low level jazyka (například C) pro tvorbu systémového jádra. Sami výzkumníci v závěru připouštějí, že v oblastech, kde je požadavek na bezpečnost, je použití vyššího jazyka velmi přínosné. Použití jazyka Go by zabránilo zneužití 40 z celkově 65 CVE linuxového jádra z roku 2017, pro které existuje patch. Samotné Go, na kterém Biscuit závisí, mělo v letech 2016–2018 celkem 14 CVE."
Zprávu jsem nečetl, nedostanu se k tomu dříve než o víkendu, ale zarazilo mne toto tvrzení, protože mi nepřipadá že by s rozkvětem HLL klesaly počty CVEček, často to záleží na důslednosti programátora či designera a taky jádro je v podstatě kritické místo nasazení takže ... Co ty si o tom myslíš?
-
počet CVE může být zavádějící číslo, osobně bych viděl metriku podle typu chyby, její závažnosti a náročnosti k odhalení. Zvyšuje se tlak na testování, vznikají automatizované nástroje k hledání chyb, řada firem vyčlenila celé oddělení prohledávání použitého SW, vynaloženě úsilí může korelovat s počtem objevených chyb.
Podle mě HLL nebude přinášet automaticky nižší počet chyb či úplnou bezchybnost, ale zlevní vývoj při zachování nebo zlepšení bezpečnosti. Určitě by se o tomhle mělo diskutovat, ta studie je velice kvalitní materiál k prostudování.
-
Na začátek, naprosto nerozumím těm mínusům u tvého komentáře.
Souhlasím, že HLL sám o sobě není zárukou bezpečnosti. Paradoxně (jak už tady myslím někdo zmínil), teoreticky může být těch chyb více, pokud se díky menší vstupní bariéry k programování dostanou naprostí laici. Na druhou stranu, tohle nemůže být metrika a všeobecně platí, že C je značně náchylné na paměťové chyby a jazyky jako Go nebo Rust byly od začátku tvořeny s cílem tyto chyby buď úplně odstranit, nebo jejich množství minimalizovat.
Při rozboru chyb (§8.2) se uvádí, že například 14 chyb jsou algoritmické chyby, kde jazyk nehraje žádnou roli. Ale ty paměťové chyby prostě nevzniknou. Jestli existuje nějaký jiný typ chyb (jak tady vyvozuje zneuznaný expert "j") se zatím nepotvrdilo.
Nezanedbatelným přínosem HLL jazyka je ale rychlost vývoje. Ať chceme nebo ne, vývoj kernelu v C prostě trvá nějakou dobu. Je zajímavé, že nikdo zde neupozornil na to, že v poměrně krátké době vzniklo 50 tisíc řádků vysoce sofistikovaného kódu. A't už se nám to líbí nebo ne, projekty jako Docker nebo Kubernetes (ale i další v jiných jazycích) by prostě jen tak nevznikly, pokud by měly být psány v C.
-
null null (neregistrovaný)
@ivoszz
Ty mínusy jsou kvůli tomu nicku ;-) ale já je jako přihlášený stejně nevidím ... :-D
Teoreticky je to další vrstva > další zdrojový kód > další potenciál pro vznik chyb (třeba implemntačních). Tak to prostě bývá. Zvýší ze zájem, zvýší se záběr, počety funkcionalit, termíny, více vývojářů různých stylů .... a už to jede. Tak to možná myslel. Ale to je těžko říct. Dokud to nevystaví světu a tlaku na 10 let, tak se dá těžko soudit jak to dopadne. Proto se to i mě zdá hodně sebevědomé. Takových proklamací už tu pár bylo.
Každopádně jazyky dalších vrstev postupně přicházejí - od pár dírek na válečku až po ... a zároveň i úměrně s požadavky uživatelů a možnostmi HW, takže by to byl logický (po)krok. Stejně určitě jednou přijde.
Určitě je dobře že někdo něco takového zpracoval i kdyby výkonostní ztráta vyšla 50% protože jinak bysme byli pořád pouze v rovině spekulací.Pokud nic nezanedbali tak nějaký závěr a přínos to prostě je tak nebo tak. -
null null (neregistrovaný)
@ivoszz
:-) to "do určité míry vyvrací" skutečně není zas tak sebevědomé, seběvědomé mi připadlo spíš to co vyplívá z toho odstavce, tedy že
"Sami výzkumníci v závěru připouštějí, že v oblastech, kde je požadavek na bezpečnost, je použití vyššího jazyka velmi přínosné."
- sebevědomé ve vztahu k těm výzkumníkům. Myslím že na takové polo-opatrné tvrzení má každý právo, sám na to nemám nijak podložený názor, ovšem to by ta práce IMO musela být o něčem jiném s jinými důkazy myslím ...Takové tvrzení "(Java je 4x rychlejší než Go)" je IMO na stejné úrovni jako by členové automotoklubu hodnotili auta podle maximálky napsané na tachometru
-
Dneska snad už nejsou devadesátá léta, a máme například real-time garbage collection. Má to i své mouchy, ale rozhodně nejde o styl "a teď se to celé na půl minuty zastaví, protože probíhá GC".
https://en.wikipedia.org/wiki/Tracing_garbage_collection#Real-time_garbage_collection
ČLÁNKY DO MAILU