Názory k článku
Komprese RAM od Meta míří do jádra

Tohle se cituje hodně, ale obvykle je vynechán detail, že to vyžaduje speciální hardware, který teď "nikdo" nemá a je otázka, zda někdy bude běžný.

Tím speciálním HW co nikdo nemá myslíte přímo RAM?

Ne - jde o hw akcelerator - dekompresor - mezi radicem pameti a interni cache v cpu.

Sedi to cca na te urovni, kde se nyni dela transparentni sifrovani.

Pripomina to spis transparentni hw-dekompresi textur v GPU.

A co ten akcelerátor má? Nějaký arm.? Je součástí CPU respektive řadiče pamětí pokud je v CPU integrován? Nebo je na desce? Obojí? Nebo se sním možná počítá až v dalších generacích a to třeba jen u serverových řešení(už je?) ve kterých má asi největší smysl? Díky.

Měl to Intel QAT (QuickAssist Technology), ale moc se to neujalo.

Pro LZO a ZSDT stačí CPU, hlavně při dekompresi, o které teď psali. Komprese bude pomalejší a asi SW označí ty stránky, co se nebudou moc měnit a budou se číst.

Velmi vtipné. Však si ten CRAM u sebe zkuste rozjet...

Jo, vidim ze tam neni ani primo identifikovany ci jenom naznaceny o jakou platformu by se jednalo (tipuji spis ARM, kde se da flexibilneji pribastlit nejaka jednotka).

Kdyz jsem videl ze to pracuje na urovni cache-line (tj. 64 byte), tak jsem si rikal - jak si to poradi se zapisy - ze se to bude hodne fragmentovat (ale teoreticky by to slo resit COW stylem, nebo grupovanim do pools, kde jsou seskupeny zakompresene varianty stejne velikosti). A oni to zabiji tim, ze je to R/O.

Jsem zvedavy co za system/aplikaci tohle realne vyuzije, podle me o RO stranky typu "code" jim nejde, programy nezabiraji vetsi gigabajty, ze by se to oplatilo resit. Tak mozna nejake read-mostly / append-only databaze, kde by se stara nemenna "sparse" data dali premigrovat do CRAM. Urcite to neni vhodny na data s velikou entropii.. tam by komprese uz nepomohla.

Další level úspory by mohl být, že "AI" bude generovat stránky RAM s obsahem podle odhadované potřeby, dle vzoru generovaných mezisnímků v některých hrách.

To už bude něco jako: https://oasis.decart.ai/starting-point
kde se generuje za chodu celý obsah.

PS: Rozežranost dnešních aplikací je na pováženou.
Má databanka Casio měla 11KB a vešlo se tam toho docela spousta..

Tyjo, to je dobrá úchylárna. Otočíte se o 180 stupňů a mapa je úplně jiná. Tak snad by to nedopadlo stejně:))

Tak samozřejmě. A všimul jste si, že šlo o jednoúčelové specifické aplikace psané přímo pro konkrétní hardware, s minimálním uživatelským rozhraním a přesně definovanou funkcionalitou, většinou jedním UC a flow.
Dnes taky není problém napsat aplikaci která zabere pár KB. Jenže pokud má podporovat různé platformy, moderní GUI, unicode, případně síťovou komunikaci, zabezpečení a další věci, začne paměťová náročnost pochopitelně růst. (stačí přidat podporu TLS a HTTP protokolu, o tom jsem se přesvědčil na ESPčku kolik to potřebuje paměti :-D)
A hlavně -- extrémní optimalizace stojí dost času, což je dost peněz. Při cenách paměti se to fakt nevyplatí. A to ani při dnešních cenách.

Webové aplikace mě živí a věnuji se jim >30 let.

Nic z toho co zmiňujete, v mých očích, neospravedlňuje "šílené" nároky mnohých aplikací.

Vůbec nemusí jít o "extrémní optimalizace" i když to co používají milióny lidí a firmy z toho inkasují miliardy by si i ty "extrémní optimalizace" zasloužily.

Tenhle člověk k tomu má víc podrobností:
https://www.youtube.com/watch?v=t992ul_IKtc