Vlákno názorů k článku
Chrome pro Windows poprvé v 64 bitech (betaverze)
od Milan Keršláger - Prohlížeč musí v paměti držet obrovské množství objektů...
-
Prohlížeč musí v paměti držet obrovské množství objektů (elementy stránky), ať už v původní podobě (JPEG), připravené (dekomprivovaný JPEG), zpracované (změna měřítka obrázku), vyrenderovanou stránku (bitmapa přes několik obrazovek) a to pro všechny otevřené taby (plus spoustu metadat okolo). To je tak náročné a komplikované, že klasická správa paměti v OS (malloc) se nedá použít a prohlížeč tedy používá svoji vlastní (mezivrstva k malloc). Dělá to hodně programů. Na 32bitové architektuře je ve Windows k dispozici jen 2GB RAM na proces, když odečteme režii procesu, knihovny, zásobník atd., zůstane zhruba 1GB RAM. To je pro prohlížeč extrémně málo, a proto jeho interní správa paměti implementuje též vlastní odkládání na disk (což je další pěkná pakárna a musí to být navíc co nejrychlejší). Ladit takového správce paměti není žádná sranda a dodnes všechny prohlížeče trpí většími či menšími memoryleaky. A ve Windows je to ladění o to horší, že nejenže nemáte zdrojáky systému a jeho základních knihoven, ale nemůžete ani nalezené chyby opravit, což je pro vývojáře úplně nejhorší varianta (a nevíte, kterou chybu Microsoft v příští aktualizaci opraví nebo ještě více pomrví). Proto se nikomu dlouho nechtělo do tohodle bahna šlápnout a ráchat se v něm (a už se to dlouho testuje a ještě dlouho bude). Na 64bitovém systému je vše jednodušší, protože paměťového prostoru je mnohem více, než mizerné 1GB. Otázka však zní, zda přechod na 64bitů něco přinese uživateli v tom smyslu, že to novější řešení bude sice jednodušší (a laditelnější), ale bude zase plné nových chyb, které jsou už u stávajícího 32bitového řešení vychytané. Samozřejmě do té paměti se musí dle situace vejít i pluginy, JavaScriptový kód, jeho datové struktury atd.
-
Lael Ophir (neregistrovaný)
Vývoj 32-bitové a 64-bitové verze samozřejmě může zvládat stejný počet programátorů. Pokud je kód rozumně čistý, prostě ho přeložíte pro 32-bit a 64-bit cílovou platformu. Odlišností pro 32-bit a 62-bit build bývá někde mezi žádnou a několika málo.
Testování samozřejmě musí proběhnout dvakrát, ale velká spousta testů proběhne automaticky bez jediného zásahu operátora.Ono se do 64-bit verze autorům SW nechce hlavně proto, že je to práce navíc (většinou jde o úklid příšerností napáchaných kdysi v historii projektu), uživatelům to zpravidla nic nepřináší, a je pak nutné testovat a podporovat dvě separátní verze, protože řada uživatelů má dosud 32-bitový OS.
-
Karel (neregistrovaný)
Co jsem migroval programy z 32bit na 64bit (C a C++), tak rozdíly v programu jako takovém nebyly vůbec žádné. Veškeré nutné změny se točily kolem použití datových typů s předpokladem o velikosti. Dokud je na všech místech stejný typ, tak rekompilace funguje. Legrace to je až když se přetypovává (vstup int, výstup int32), nebo se použije struktura, do které se mapuje binární soubor. Každopádně tohle všechno jsou chyby programátora. Aplikaci, kde by se musela opravovat logika kvůli 64bitům, jsem ještě nepotkal. Vyvíjet verzi, která jde zkompilovat na 32bit i 64bit, neznamená vyvíjet verze dvě. Stačí jen jeden tým, akorát musí chápat datové typy. Kolikrát stačí rychlý úvod do <inttypes.h> a rázem nepotřebujete řešit 32 vs 64.
Ale musím přiznat, že funguje efekt "padajícícho h...." Pokud použijete cizí knihovnu, která na 64bitech nefunguje, tak máte problém.
-
Lael Ophir (neregistrovaný)
DOM je binární struktura, která není nijak závratně paměťově náročná. Browser samozřejmě nedrží celou vyrendrovanou stránku. V primitivní implementaci její kusy skončí v paměti grafické karty, přičemž každá fullHD obrazovka má pouhých 8MB. V pokročilé implementaci v paměti grafické karty skončí resources (vyrastrované obrázky, grafické prvky, mezi aplikacemi sdílené glyphy fontu), a při zobrazení kusu stránky se jen grafické kartě řekne, jaké resources má kam naházet. Originální obrázky si po vyrastrování můžete nechat na FS v cache, nikdo vás nenutí je skladovat v paměti.
32-bitové procesy na 62-bitovém OS (o čemž byla řeč) mají 4GB adresní prostor, pokud má image nastavený flag IMAGE_FILE_LARGE_ADDRESS_AWARE. Navíc vás nikdo nenutí používat jediný proces. Vzhledem ke stabilitě různých pluginů se naopak vyplatí použít worker procesy, aby v případě problému na jedné stránce přežil obsah ostatních stránek.
Aplikace se píšou podle dokumentace API, nikoliv podle vlastností API nalezených metodami pokus-omyl nebo skouknu-zdroják. Cokoliv není popsané v dokumentaci, je nedokumentovaná vlastnost, a v příštím buildu to může být úplně jinak.
Pokud ladíte vlastní správu paměti, nepotřebujete k tomu zdrojáky systémových knihoven. Nalezené bugy samozřejmě můžete hlásit MS. Postup je stejný jako u open source: nahlásíte bug (u open source klidně i s opravou), a pak čekáte, jestli se to dostane do příštího produktivního buildu, což vám ani v jednom případě nikdo nezaručí. Plus vám nikdo nezaručí, že se ten nový build dostane k vašim uživatelům. Rozdíl je v tom, že knihovny od MS jsou dlouhodobě používané a stabilní, takže zřejmě nebudete pokusný králík, kterému se s každým buildem mění vlastnosti knihovny pod rukama.
