Vlákno názorů k článku
Chrome spotřebuje 10× více paměti než Safari
od Ondra Satai Nekola - Měření na nic. Pokud je část procesů vynechaná,...
-
Ondra Satai NekolaZlatý podporovatelMěření na nic. Pokud je část procesů vynechaná, tak to reálně může být jakkoli.
-
Přijde mi to jako nonsese. Když si vezmu, že Epiphany, které má stejné vykreslovací jádro jako Safari a troufl bych si tvrdit, že jinak bude ještě úspornější, po načtení jedné prosté stránky (duckduckgo.com) v paměti bere přes 200 MB... Ano, samotný proces Epiphany má krásně pod 100 MB, ale pak si člověk musí přičíst další procesy WebKitu, které to startuje.
-
Filip JirsákStříbrný podporovatelBlink je fork WebKitu, nezdá se mi pravděpodobné, že by tam udělaly takové změny, že by se paměťová náročnost řádově zvýšila. Podle mne bude rozdíl spíš v tom, jak prohlížeč jádro používá. Používá Safari také přístup co záložka to proces?
-
Spousta optimalizací je vně webového jádra. Např. sdílení procesu a RAM cache mezi kartami, odswapování na disk viz komentář níže nebo komprese RAM (např. stránka stáhne JPG, dekomprimuje na bitmapu, kterou pak kreslí při každém překreslení obsahu stránky - pokud by bitmapa v RAM byla komprimovaná rychlým algoritmem zlib, tak je to technicky PNG - ve skutečnosti je bitmapa ne v systémové RAM, ale ve video RAM /GPU akcelerované kreslení stránky/, a tady má Apple výhodu vlastního hardware: HSA architektura umožňuje CPU a GPU pracovat se stejnými daty ve sdílené RAM, tj. není třeba je duplikovat /data ve VRAM se obecně berou jako dočasná, takže se drží kopie v RAM a do VRAM průběžně nahrává jen ty nejčastěji používané/ a není pro něj problém implementovat stejný kompresní algoritmus i pro svoje GPU, takže pro překreslení stránky není třeba bitmapu dekomprimovat /GPU mají komprese textur už dávno, ale nevim o žádné lossless/).
-
Prostě tady PC a Android světu ujíždí vlak. Sdílená GPU na PC a Android nejsou HSA, takže je třeba bitmapy kopírovat sem a tam a zabírají víc místa. Podobně např většina mobilů má pruhy v gradientech na OLED displeji, protože výrobci mobilů nedokážou upravit hw GPU, driver GPU nebo vykreslovací kód OS (i když je Android opensource, tak na tohle by potřebovali lepší programátory než jen na vlastní launcher), aby obešli nedostatky OLED v tmavých odstínech. Jediná výhoda je, že Apple si říká o pořádnou marži (proč ne, když nemá konkurenci), takže PC/Android ho dotahává hrubou silou (za cenu menší výdrže na baterii při zátěži, ale cenově to i tak může být levnější než Apple).
-
To je sice pěkné, že jste si dal takovou práci přijít na to, čím by to mohlo být, že Safari žere tak zázračně málo RAM, ale ušetřil byste si čas, kdybyste se podíval na tu odkazovanou diskusi na Ycombinatoru.
Tam byste se dočetl, že autor k takovým číslům došel, protože opravdu nezapočetl všechny renderovací procesy, protože ten nástroj, který používá, to neumí. Když tam někdo použil nástroj, který to seskupení všech procesů Safari umí, dostal se na 750-850 MB při dvou otevřených stránkách. Tedy zhruba na úrovni toho, co je reportované u Chrome. Senzace se nekoná.
-
1) Čím složitější řešení, tím lepší potřebuješ inženýry a programátory. Proto taky AMD architekturu HSA opustilo. Bez spolupráce od OS a vývojářů aplikací by přínos nebyl takový, aby ospravedlnil tu makačku. Neříkám, že je to špatně - akorát uznávám práci Apple, že se snaží vyždímat každý skrytý kousek výkonu, aby byl konkurenceschopný (koneckonců Zen 3 je i jako CPU obecné architektury výkonnější než M1; ale takhle Apple překonal Zen 2 a Intel, což pro přechod na vlastní CPU není vůbec špatný).
2) Sdílená paměť neznamená HSA. VRAM na Android SoC, Rhapsbery Pi a Intel/AMD iGPU se chová jako samostatná (logická) RAM, jen je fyzicky namapovaná do prostoru systémové fyzické RAM (jde ale měnit její velikost za běhu). U primitivnějších řešení se data do ní musí kopírovat, tj. načtu z disku JPG, dekomprimuju na bitmapu, zkopíruju její bajty do VRAM (fyzicky na další místo ve fyzické RAM). U lepších řešení se označí paměťové stránky dekomprimované bitmapy jako grafická paměť, tj. zero-copy (myslím, že to takhle má nějakej rok AMD; nejde to použít vždy - někdy si aplikace chce ponechat bitmapu pro další práci). Nicméně ani u toho lepšího řešení nemůže s bajty bitmapy ve VRAM pracovat současně CPU a GPU (stránky paměti jsou buď RAM, nebo VRAM - ne obojí).
Tohle řeší HSA (Heterogeneous System Architecture): ačkoli s daty pracuje současně CPU (načtení bajtů JPG z disku), ISP (image signal processor; dekomprese JPG na bitmapu) a GPU (použití bitmapy ve vykreslení stránky), tak bitmapa je ve fyzické RAM jen 1x (a současně na ní mohou přistupovat všechny procesory a koprocesory, včetně funkčnosti cache). -
Ani 2 jadra CPU bez synchronizace nemuzou pracovat se stejnymi daty soucasne. Pro svuj argument potrebujes lepsi priklad, nez dekompromaci obrazku. Idealne neco, kde CPU a GPU potrebuje spolupracovat soucasne a nejlepe pouzit nejake atomicke operace. Pokud jenom predavas buffer mezi koprocesory, tak to bohate staci zero-copy.
-
Když program na 2 CPU jádrech pracuje s jedním kusem paměti současně, tak je pro něj cache transparentní. Nemusí v kódu programu řešit nějaké zamykání paměti a synchronizaci. Tohle je u CPU jader implementováno všude. U iGPU to má Intel - tam se iGPU chová jako další jádro CPU (proto třeba na chromebookách odpadne jedno kopírování obrazu webové stránky). Nevím, jak dnes, ale když AMD opustilo HSA, tak iGPU sice bylo zero-copy (např. nahrávání textur do "VRAM"), ale CPU musel počkat na iGPU, aby s ním dohodl změnu paměťové stránky, že bude patřící pro GPU.
-
Přístup více jader CPU je cache transparentní ale stejně se synchronizaci nevyhneš jinak se dostaneš do dirty read nebo dirty write situace.
Stejně tak je synchronizace nutná u HSA. CPU nemůže měnit bitmapu textury, ktrou GPU zrovna používá k rasterizaci.
RTX 3080 má paměťovou propustnost 760GB/s... jaká by asi musela být konfigurace RAM HSA řešení, aby nebrzdila takovou GPU když současné ddr4 v čtyřkanálovém zapojení mají propustnos řádově nižší?
-
Když říkám, že není potřeba synchronizace na aplikační úrovni (např CPU čekající na iGPU, aby mohl dohodnout zero-copy), tak to znamená, že je tam nějaká automatická low-level (takovou, jakou známe u vícejádrových CPU).
GPU stačí porovnávat s podobným výkonem (iGPU x dGPU), tam vyjde iGPU jako efektivnější (dosáhne daného výkonu s menší propustností RAM). Mimochodem Apple si pomáhá větším počtem užších kanálů, takže různá jádra CPU a GPU mohou současné šahat do RAM (latence), i když součet rychlostí do RAM je stejný jako 2kanalálové klasické zapojení.
-
:D no uz jsem to skoro vzdal, protoze Ladislav Zima na jednoduche problemy odpovida zdlouhavym vysvetlovanim :) ....
on ti na to zase muze rict, ze ty ten JPG musis nejdrive nacist pomoci CPU do RAM a pak to presunout na GPU, na coz mu reknes zase ty, ze se to udela pomoci DMA takovou a takovou rychlosti, na to ti rekne, ale to tam stejne musis mit 2 kopie jednoho obrazku a pak to zabira zbytecne misto, na to my ty reknes, kolik GB pameti ma to GPU a jak velky by ten obrazek musel byt, aby to melo nejaky vyznam a na to on ti zase odpovi, ze ne vsechny zarizeni maji takove parametry a muzou volne rozdavat pamet a na to ty mu reknes, ze zrovna ten Apple m1 ma nejmene 8 GB a to uz kdyz si teda koupis Apple, tak je to vylozene zebracka varianta, ktera i tak vyjde na brutalni prachy
Tak to muzeme takto zkratit a jit dal ....
