Vlákno názorů k článku Firefox bude mít nové jádro Quantum, využije nový hardware od j - jj, je potreba aby to sezralo aspon 16GB...
-
j (neregistrovaný)
Prostou dedukci mily watsone. Novy HW = prevazne vice CPU a vice ram => "musime to vyuzit" ... takze to sezerem cele, protoze aktualni stav je takovy, ze ff spolehlive (ve 32bit) sezere komplet cele 4GB ktere muze (a nekdy i vic, nez se tedy zhrouti) a 100% zatizi to jedno CPU na kterem bezi.
V 64bit verzi uz ted vpohode schroupe 8GB ram (na vic sem se zatim nedostal, coz neznamena ze to nelze) a az bude mit pristup k vice cpu, tak je sezere zcela zarucene taky.
A to nejsem zrovna priznivec stovek otevrenych tabu. Kdo je, bude na tom jeste hur.
Vazne by me zajimalo ... proc ma neco co nic nedela a vejde se spolehlive do 10MB (per tab rekneme) sezrat v ram 10x vic. A jeste vic by me zajimalo, proc i jen spustena nicnedelajici aplikace behem par dnu znekolikanasobi alokovanou ram. Rizeni vesmirnyho letu se vejde do par kB.
-
To, že to žere gigabajty, je dané tím, že to cachuje, co to jde. V zásadě je to tak správně, nevyužitá RAM znamená plýtvání. Problém je v tom, že je dost těžké napsat aplikaci tak, aby na to používala jenom tu část RAM, kterou nic jiného momentálně nepotřebuje. V ideálním případě by taková aplikace cachovala ne do RAM ale rovnou na disk, a nechala by kernel, ať si to v RAM cachuje sám podle toho, jak uzná za vhodné.
Že Firefox a jiní postupně nabobtnávají je dané z velké části tím, že jsou napsané v C++, kterýžto jazyk prakticky garantuje neřešitelné memory leaky (i přes všechny více méně krkolomné snahy v něm používat garbage collector, jako to dělají Firefox i Chrome). Právě správa paměti je jedna z věcí, kde lze s přechodem na Rust doufat ve výrazné zlepšení.
-
Filip JirsákStříbrný podporovatelTohle by chtělo jaderné API, které by umožňovalo paměť dělit do kategorií podle důležitosti a v případě potřeby ji od té nejméně důležité uvolňovat. Ostatně ten samý problém řeší virtuální stroje, kde se to obchází balonovými ovladači. V jádru myslím nějaké náznaky jsou, ale asi to neodpovídá současným potřebám.
-
j (neregistrovaný)
Ehm lol ... na tyhle planete neexistuje zadna appka nenapsana v C/C++, ktera by uvolnovala ram. Ani jedna. Videl sem nekolik zoufalych javistu a jeste vic zoufalych C# ... ktery se znazili "nejak" dotnutit svuj vytvor aby ram uvolnil, ale je to proces zcela zarucene zcela nahodny. A presne stejne to funguje vsude, kde "se to nejak samo".
Pokud v Ccku chci dealokovat ram, tak to muzu udelat, a to naprosto primitivne jednoduse, a stane se to. Pokud sem prase a netusim co delam, tak samo budu tak maximalne alokovat dalsi pokazdy, kdyz neco zavolam ....
-
ff (neregistrovaný)
S velkou silou prichádza veľká zodpovednosť.. čo sa týka C++ ..
Aj v Jave sa dá napísať moloch ktorý zožerie celú ramku (videl som systém v Jave(tučné platené riešenie) ktorý sa musel pravidelne reštartovať pretože Garbadge collektor zožral všetku ramku až ho zabil OOM killer :D ). Idea za Rustom vyzerá uvidíme aká bude realita.
Ale myslím že ak človek použije rozumne odladený framework, a používa pokročilejšie konštrukcie typu shared pointer a podobne dá sa veľa problémom vyhnúť a je to lepšie ako používať akýsi globálny garbadge collector.Myslím že v tomto prípade ide o to že ff cachuje každú otvorenú stránku a úplne každú zmenu na stránke každých x sekúnd/minút čo samozrejme vedie k tomu že to postupne zožerie pamäť - ktorá sa síce môže uvoľniť podľa potreby, ale v praxi to moc dobre nefunguje.
Keby sa s pamäťou robilo úspornejšie tieto problémy by nenastali (v kombinácii s memory leakmi)..
-
Ondra Satai NekolaZlatý podporovatelA nenapadlo tě, že řízení vesmírného letu je o něco snazší problém?
-
Ondra Satai NekolaZlatý podporovatel
Mají se tvářit, že dnešní HW je koncepčně devadesátkový HW a že se v SW inženýrství za posledních X let nic neposunulo?
