Pojďme programovat elektroniku: Jak to, že je průměrná webová stránka stejně velká jako Doom?

Tento článek mi připomněl historky, co nám říkali ve škole staří praktici. Rekonstruovanou soupravu metra řídili (a možná ještě řídí) procesory 80196 (bráška 80186 s nějakými periferiemi navíc). Takže bylo potřeba normalizovat veličiny do 8 bitů. V případě rychlosti se transformoval rozsah čísel 0-255 na rozsah 0-81.92 km/h (maximálka je 80, tedy je to akorát). Jeden dílek pak odpovídal 1/32 což je 0.03125 km/h, tedy rozlišení víc než dostatečné. Ale teď bylo potřeba udělat drážní zkoušky, kde se musí vozidlo zkoušet při +20% tj. nějakých 96 km/h, což je mimo rozsah a pro ty zkoušky prý musel být software upravený.
Podobnou historku nám vyprávěl jiný učitel u vlaků dnes známých jako city elefant. Tam šlo pro změnu o teplotu, kterou do 8 bitů ukládali jako -128...+128°C (tedy klasický shortint). Na zkušebně to fungovalo výborně, ale přišlo léto a strojvůdci si prý začli stězovat, že jim ta mašina netáhne (tak to říkal ten učitel, z jiných zdrojů jsem slyšel horší popis situace, typu že hoří). Ukázalo se, že se tak stává, když teplota dosáhne 128 a víc stupňů, které model vidí jako -128 a víc a výpočet pak pochopitelně selhává. Přitom třída izolace dovolovala 155°C. Už si nepamatuju řešení, ale předpokládám, že se posunula nula tak, aby rozsah odpovídal reálným možnostem (je logické, že pod -100 neni ani na sibiři).
Posledních několik let pracuju s procesory v plovoucí řádové čárce (výpočty v plovoucí čárce probíhají stejně rychle jako v pevné), takže mám o starost s normalizací a převodem na počítačové jednotky méně. Ale ona vzpomínka na doby, kdy člověk musel řešit rozsah a rozlišení (třeba jestli stačí rozlišení 0.05Hz pro kmitočet sítě?) na mě dýchla i když dřevní doby (typu SAPI) osobně nepamatuju. Zrovna nedávno někdo vzpomínal na SAPI a že ho arduino strčí ve většině parametrů do kapsy.

Šlo by to ještě stlačit dolů, v objemu přenášených dat.
Je dobré si uvědomit, že data, která se přenáší (teplota, vlhkost,...) jsou spojité funkce v čase, s relativně pomalou změnou, tj. stačí přenášet jen informaci o relativní změně.Při troše vůle a dosti rychlém vzorkování všech 4 veličin, by to tudíž šlo stlačit i na 1 Byte.

Názor byl 1× upraven, naposled 31. 1. 2017 22:05

Mnouhem lepší, než používat pole a do něj to kopírovat, je používat __packed strukturu, např.
typedef struct __attribute__((packed, aligned(4))) {
float teplota;
uint8_t vlhkost;
...
}MereniJe to na jednom místě a v rámci celého zpracování se dá jen předávat pointer na ni. Také existuje 16b half precision float... ale na malém MCU je lepší se floatům zcela vyhnout, knihovny sežerou spoustu paměti...

Mě se ten článek moc líbil, ale měl bych jednu připomínku. Před tím, než se dělají takové optimalizace, které žerou čas a snižují čitelnost dat normálním člověkem je dobře se zastavit, vylézt na nejbližší strom a podívat se na to s větším rozhledem. Ja se přiznávám, že se v síťových komunikacích příliš nevyznám, ale myslím, ze tady ke každému odeslanému balíčku nutno připočíst TCP/IP header a IPV4/6 header. To je 40-60 bajtů. Nevím, co si ještě navíc přidá HTTP/HTTPS, pravděpodobně ještě víc. Takže jestli jde vlastní informace jako 11 bajtů nebo 8 nehraje roli. Není to myšleno jako kritika (článek je přece příklad, kde je důležitější stravitelnost informace), ale jako poznámku navíc...

Tak mi na mysl vytanula poučka: Musíš-li použít assembler, máš ve skutečnosti slabý hardware.

Kapacitu pocitame na intalace Dooma, rozlohu na fotbalova hriste a nesmime zapomenou na silu 162 kavovaru. At zije SI soustava.

Optimalizovat program tak, aby využíval jen nezbytně nutné množství RAM a HDD.... a mít celý projekt třeba dražší o stovky tisíc či dokonce miliony korun kvůli vynaloženému času programátorů... nebo si přikoupit moduly RAM za pár stovek či tisícovek korun?

Při používání jquery mi tenhle článek přišel vhod k otevření očí 😀

Největší chybou při programování Atmelů je používat pohyblivou čárku. To se musí přilinkovat knihovna math, která zabere spoustu paměti a program běží dlouho. Pokud ta čidla nevysílají ve float formátu, ale např. bitově, je v tomto případě mnohem jednodušší pracovat jen s integrem 8 nebo 16 bitů. Výpočty jsou mnohem rychlejší a desetinná tečka se přidá až na zobrazení. Vím o čem píšu. Dělali jsem systém, který měřil asi 20 hodnot a tři veličiny reguloval (PID) a celé jsme to udělali v celočíselných hodnotách.

koukal jsem na porad o programovani a podle vseho nejvetsi machri jsou v NASA(druzice a autonomni vozitka). Omezeny prisun energie + zareni (minimalizace vseho elektro a stineni) + predpokladana zivotnost (na druzicich mnoho let) + spolehlivost (nemoznost servisniho zasahu).Uzasna optimalizace na praci s fotkama, komunikaci proste vsem. Pro velkou vetsinu ostatnich aplikaci je to desnej overkill ale....

Za nejzajímavější považuju, kolik lze popsat textu o tak samozřejmých věcech 🙂

F29 Retaliator - cca 100 kBNa javascript používám Yesscript do Firefoxu (blacklist) - oblíbené stránky, které fungují i bez JS to výrazně urychlí

Zrovna vcera jsem resil jak neco nacpat do AtTiny85. Po odecteni bootloaderu je k disposici 6kB flash a pro beh pak 512b SRAM. To pak clovek sahne po struct s urcenim bitu pro hodnoty nebo eliminaci float velmi rad. Protoze proste nic jineho nezbude. Pokud clovek nepouzije float tak usetri cca 2kB vysledne binarky a to uz je znat.

I v dnešní době se dělají extrémně optimalizované díla.
V tomhle 64kB demu máte film s hudbou od mikrosvěta po makrosvět.
Do 64 kilobajtů dat se dá toho narvat opravdu hodně.
https://www.youtube.com/watch

No ono vse souvisi se vsim. Jsem z generace ktera zacinala na 8mi bitech a programovani v assembleru ( nebo primo ve strojaku ) bylo jaxi normalni. Nevim proc, uz 20let jsem to nepotreboval ale porad si pamatuji opcode z CPU6502 🙂.
No a tak jak se postupem casu na bity nabalily MB/GB/TB tak se na programovani nabalila skupinka "projektaku, analytiku, architektu, lead testeru" ... a vysledek 🙂 to znate asi kazdy sam ... Asi patri k nejake programatorske cti vytvorit kod "ktery proste funguje" a nesezere 200MB na totalni banalitu alespon pro nektere ...

Kuba moc na zive nezapada, co?

Že zrovna reklamní farma s názvem Živě.cz filozofuje o tom, proč jsou stránky velké...

"Pojďme si připomenout, jak přemýšleli všichni vývojáři kdysi dávno"
"..všichni kodéři maximálně nízkoúrovňoví"Programatori pracuji i s binarnimi daty. Koderi pouzivaji vyhradne textova data (CSV, JSON atd). Koder, ktery objevi existenci binarnich dat a manipulace s nimi o tom napise clanek. "Heuréka, zaplnili jsme celý bajt"
Uvahou dojde k zaveru, ze to patri k minulosti.Technika redukce dat az do binarni urovne je platna a pouzivana neustale.
Pouzivaji ji vyrobci HW, Embeded zarizeni a na to nabaleneho SW atp.
Staci si vsimnout jak jsou ruzne ulozeny informace k zarizenim "chipset, sbernice, CPU, GPU atd., zaznamy v reg. windows. ruzne transportni protokoly na fyzickych vrstvach atd". Hodi se pri reseni ruznych problemu s nedostatkem pameti => rychlosti.
( Bitove operace patri k tem nejrychlejsim-viz. mozne uziti bit.posunu pro nasobeni pri optimalizaci)Co se tyka usetreni el.energie pri posilani (Kazda komunikace ma svou rezii). Obecne je asi nejlepe poslat co nejvice dat a to nejmenekrat.Analogie s postou - zaplatim mene za jeden velky balik nez za X malych.

Názor byl 5× upraven, naposled 30. 1. 2017 03:18

Myslím že je to zajímavá retrospektiva do hlubuin programování a dob kdy webová stránka s 200kb+ byla považována za šlendrián a dob vytáčeného připojení od Českého Telekomu 😀 .
Líbily se mi i hrátky s dvojkovou soustavou, ovšem myslím že by to šlo i v desítkové a poměrně snadno.
Teplotu převedeme na celé číslo jak bylo napsáno v článku a k tomito číslu přičteme konstantu:
0,25° - 0,49° = 64 ; 0,5° - 0,74° = 128 ; 0,75° - 0,99° = 192
tedy: 35,36°C ==> 35 + 20 = 55 + 64 = 119 a toto číslo odešleme. Hotovo.
Zpětně je to trošku složitější, ale s podmínkou pokud se číslo nachízí v intervalu pak odečti 63,75 si bohatě vystačíme.
RC

Podobny triky jsem pouzival pri programovani - u cca nekolika desitek milionu ulozenych hodnot v RAM uz se dalo poznat poznat kdyz se velikost stahla o par bytu.
Nicmene v tomhle pripade nechapu. Nebude velikost datove casti packetu pri prenosu tak jako tak vetsi nez velikost zpravy pred redukci? Aby nahodou ve snaze usetri energii pri prenosu se nespotrebovala na prenos ta sama energie, ale zato se spotrebovalo vic energie v procesorovych cyklech na orezavani cisel a bitove posuny. 😃

JavaScriptový framework se stahuje typicky jen jednou, pak už je v cache prohlížeče (na disku). Ovšem grafika místo zabírá (obrázky, reklamy, pozadí). Když tam je JPEG, pak to může být 10x až 20x zkomprimováno, takže ze 4MB je rázem 80MB nekomprimovaných dat. A když se to vyrenderuje do webové stránky (tj. do rolovatelné bitmapy), tak to máme (s bitmapama textu) klidně 200 MB. A proto jsou ty prohlížeče tak nenažraný. A proto se s tím nic moc nedá dělat (kromě blokování reklamy).

Kdo není úplný *etard, tak ví, že i dnes záleží na "každém bajtu" speciálně u webů!Velký web = pomalejší načítání = uživatelům se hůře používá + vyhledávací enginy dávají nižší rank a nižší pozice = na stránku chodí méně lidí = MÉNĚ PENĚZ ať už její provozovatel dělá cokoli (pokud to není státní úřad 😀 😀).Navíc zbalastěný web se nejen déle přenáší k uživateli, ale často ho i server déle vypočítává, takže je to pak znát.Jestli má vaše průměrná stránka 2,5 MB a je narvaná scripty, které musí zpracovat server NEBO jestli má jen 250 kB a jedná se o předgenerované HTML za pomoci CMS, které se jen odešle uživateli opravdu SILNĚ poznáte na penězích!!Možná ne, pokud poskytujete něco absolutně unikátního... Ale pokud se jedná o něco, kde je silná konkurence - tak to jste bez šance. Takovou stránkou pak doslova tlačíte lidi ke konkurentovi.

Palec hore Kubovi. Za odmenu som poklikal pár reklám. :)

jojo, bejvaly to zlatý doby úspornejch webů, když se na net lezlo vytáčením na modemu a rychlost byla reálně od 20 do 40 kbps
tehdy byla stránka s článkem na zive.cz načtená mnohem rychlejc než dneska na lajně0 200 Mbps, tehdy ani nebyly potřeba blokovače reklam, který dneska jsou nutností...
a úplně nepochopitelný je pro mě i to, že taková balastu zbavená stránka si stáhne nějaký 3-4 MB dat, ale zobrazení tý stránky v panelu ukousne 150-200 MB raměti...

Autor chtěl asi ukázat bitové operace, tak tu teplotu skládá, ale je dobré si uvědomit, že těch 8 bitů tam v tom floatu už je. Stejnou práci by zde udělalo vynásobení té teploty 4x a zaokrouhlení na int, nebo lze z toho floatu vytáhnout exponent přímo a prostě to celé jen posunout doprava, tam se bitové operace využijí taky.Co se týče těch webů, kde jsou pod sebou 4 obrázky na celou stránku a na každym 1 věta textu a do stránky přibaleno 10 js frameworků aby se to hýbalo, to už asi nikdy nepochopím.

Protože je na ní milion reklam.

Na někdejších sálových počítačích bylo opravdu málo paměti, třeba EC1021 měla jen 64kb na feritových jádrech, takže to zabíralo 2 skříně. A tak se takové postupy pro šetření paměti opravdu využívaly. Z tohoto pohledu je vlastně každá dnešní průměrná webová stránka v podstatě také doom? 😉