Vlákno názorů k článku Vývoj mikroprocesorů z rodiny 80×86: 32bitové čipy 80386 a 80486 od Mintaka - Díky za další nový <strike>ráno</strike> článek. Schraňuji sešitek z...
-
Díky za další nový <strike>ráno</strike> článek.
Schraňuji sešitek z konce osumdesátek s ručně vypsanými instrukcemi CPU Z80, ale u ≥386ky, tam už jsem si, až na drobné pokusy, s assemblerem nehrál.
Nicméně mě to přivádí k zamyšlení, jak by tak asi fungoval web browser, který by byl pěkně nízkoúrovňově, od základů, navržený a optimalizovaný na současné potřeby webových aplikací.
Když si vezmu i ty staré osmibity, co všechno s pár kB RAM a výkonem CPU menším, než mají dnešní IOT dávkovače na mýdlo, dokázaly, tak mám problém se smířit s tím, že ty dnešní GB RAM a výkon hodný nedávných superpočítačů, mizí kdesi v nenávratnu.
6. 12. 2024, 09:32 editováno autorem komentáře
-
Smazaný profil
Ono je to obráceně - v dávkovačích na mejdlo je zbytečně výkonej šváb jen proto, že byl zrovna po ruce někomu, kdo přišel na myšlenku dělat IoT DnM. A tak je to se vším. Kostra programátora nebo pianisty je funkčně stejná jako kostra velryby - velká mozkovna a končetiny roztřepené na pět prstíků. A přesto se velryby používají jenom jako plující vodotrysk.
-
Pavel TišnovskýZlatý podporovateljako jo, ty šváby jsou někdy hodně nadupaný. Jenže například já teď zrovna něco hledal na jeden domácí bastl a našel jsem (jen příklad, dávám nejlevnější nabídku z obou kategorií):
vylepšenej 8051, flash: 2kB, SRAM: 128B, - za 95 korun
ARM (jádro M0+), SRAM: 4kB, flash: 16kB - za 44 korun
Takže je asi jasný, že se nebudu starat o to, jak vyjít s 2kB Flash (tedy ROM) a jen 128 bajty RAM a ještě mít jen osmibitové jádro, když můžu mít plnotučnej ARM s mnohem víc pamětí, a 32bitovým jádrem (navíc i tooling okolo ARMu je příjemnější, ono céčko pro 8051 vyžaduje dobrou znalost i assembleru).
Jasně, když někdo bude těch dávkovačů mejdla dělat miliony, tak má jiný ceny (a určitě jsou nějaký PICy a AVR pod jeden dolar), ale dělat něco v 10-100 kusech, to budu raději pojídač koláčů :-)
-
Jasně, když někdo bude těch dávkovačů mejdla dělat miliony, tak má jiný ceny (a určitě jsou nějaký PICy a AVR pod jeden dolar), ale dělat něco v 10-100 kusech, to budu raději pojídač koláčů :-)
Ono i u těch velkých sérií se nakonec může ukázat, že práce, která by s tím byla navíc, vyjde dráž než ten hardware.
S tímhle má problém hlavně starší generace, která vyrůstala v systému, který verbálně velebil práci, ale v reálu učil lidi filosofii, že věci jsou drahé a práce je zadarmo. (To nemyslím nijak urážlivě, sám tam patřím, i když se snažím od tohoto myšlenkového modelu oprostit.)
-
Ted si predstav, ze jsem pred 20 lety psal do 8051 scanner na stravenky s OCR. Programoval jsem to v C (SDCC) a dobra polovina byla v assembleru. To byla dobra silenost. Tocilo to motorem, mezitim to cetlo tusim 24 bitovy CCD sensor a on the fly to dekodovalo znaky. Nebylo misto na cely radek, muselo se to stihat behem toho, jak ta stravenka prochazela strojem. Navic to bylo mechanicky pomerne blbe udelane, dost casto to zadrhavalo, tak se muselo snazit se zkratit roztazeny znak nebo naopak nafouknout prilis kratky znak. Dnes uz bych neco takoveho asi nebyl schopny napsat.
-
Myslím si, že by to o tolik lepší nebo horší nebylo. Problém není v designu web browseru, ale v designu stránek. A ty GB RAM mizí díky tomu, co všechno je v dnešních prohlížečích podporováno a pak realizováno. Dneska jen vykreslit znak na základě nějakého fontu si vezme pár MB. Od toho kresleného znaku odděluje uživatele možná i několik vrstev umožňující pracovat s vyšší abstrakcí nebo přenositelností. Podívejte se např. na možnosti unicode. Díky unicode nemusíme řešit kódové stránky, ale dříve banální úlohy převod písmen z malých na velké nebo zjištění šířky jsou kódy plus tabulky určitě přesahující desítky kB. Kdyby tu tolik RAM nebylo, tak by určitě došlo k větší unifikaci technologií na netu a k menší duplikaci kódu, knihoven. Viz např. Microsoft IE 5. Nicméně ten hw tu je, a nic nenutí vývojáře, firmy k větší optimalizaci, deduplikaci, k optimalizaci. To by znamenalo větší náklady na koordinaci, větší závislosti - větší integraci komponent - a s tím jsou spojené zase další problémy. Osobně si nemyslím, že by to bylo tak špatné - můj primární počítač je 13let starý a pořád ještě pro běžnou práci naprosto bezproblémový - stejné CPU - přešel jsem na SSD (rozhodně nemám problémy s rychlostí www stránek).
-
Souhlasil bych s tím, že ten redesing by si zasloužilo víc věcí, než jen ten browser, fonty nevyjímaje. Já třeba nechci, aby můj prohlížeč zobrazoval kdovíjaké ultrasuprdupr ikončičky, raději ať mi zobrazí třeba U+1F4A9.
Stejně tak mám v základu vypnutý JS a zapínám ho jen tam, kde chci.
Vypnout autoplay videí/hudby bývá také problém (Settings -> Autoplay -> Block Audio and Video) zdaleka nestačí. A tak by se dalo pokračovat.Re. ...odděluje uživatele několik vrstev....
No a tam někde poblíž může být zakopán pes.
Jak efektivně umí pracovat OS, který se ty mezivrstvy snaží omezit, se můžete podívat na http://www.menuetos.net/ (Dnes tam přidali vylepšené síťování a lepší podporu pro Webcam). (Pro neznalé, ASM based OS, co se i s GUI a smečkou aplikací vejde na 1,4MB).13 let staré "kompasy" to jsou u mě ty novější. Jak to má aspoň 2 GB RAM a 64bit procesor, tak už tam ženu Lubuntu, jinak nasazuji Antix a na zoufalé netbooky Puppy. Zachraňuji co se dá, dokud tomu nechcípne základovka, vždycky se nějaké využití najde.
...Tak zase zpět k tomu ESP32 s 8MB RAM....
-
Nemusíte jít do assambleru - hodně rychlý a úsporný je i Oberon os, a to je napsaný v Oberonu - což je vyšší programovací jazyk jen s minimálně optimalizujícím překladačem - je to další inkarnace Pascalu (po Module).
V ideálním případě jde napsat kompaktní produkt. Realita má k ideálu daleko. Abyste přežil na trhu, tak musíte doručit kód co nejdříve a co nejlevněji, a nemáte čas vymýšlet dokonalý kód a dokonalé protokoly. To vede k iteracím, a následně problémům se zpětnou kompatibilitou. Pokud nemáte plnou kontrolu nad produktem, tak hodně kódu produkují třetí strany, které nemají vaše znalosti, případně jedou po své linii, a nečekají až vy jim doručíte veškerá API, jelikož konkurence nečeká. Což je základ veškeré duplicity kódu, duplicity API, a tím absolutní efektivita a elegance končí. Zkusíte vyčistit kód, a hned máte problémy se zpětnou kompatibilitou a uživatelé od vás odejdou. Tohle skvěle pochopil Microsoft. Nádherně je to vidět třeba na evoluci db API - ODBC, DAO, RDO, ADO, ADO NET, .. jako celek je to brutálně neefektivní, ale je to všude a pro všechno.
Dnešní sw systémy jsou babylonské věže. Pokud máte projekty, kde jsou zainteresovány desítky, možná stovky tisíc lidí, tak to nemůže dopadnout jinak. A zákazníci nemohou měřit kvalitu kódu - vidí jenom masu, a kdo dá víc, vyhrává.
6. 12. 2024, 22:52 editováno autorem komentáře
-
RE. "Abyste přežil na trhu, tak musíte doručit kód co nejdříve a co nejlevněji, a nemáte čas vymýšlet dokonalý kód a dokonalé protokoly..."
IMHO: Přijde čas, kdy se tento způsob vývoje a myšlení vyčerpá, a další smysluplná cesta někam dál povede přes "refaktoring" i těch základních konceptů.
Aktuálním pohledem do procesů tady vidím, že zobrazení jediné stránky
19:28.83 firefox https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
má 162 procesů, které sežraly přes 15 hodin procesorového času.Za tím, že se tohle může dít, že to prohlížeč tiše akceptuje a uživatel se s tím smíří, je brutální vývoj výkonnosti celé té mašiny, zejména RAMky a CPU, který tím ovšem teče někam do odpadní roury.
Jestli je tohle
https://imgur.com/a/9jSlFlw
ta Babylónská věž, tak už je víc nakloněná, než ta v Pise. -
Já si o stávajícím stavu také nemyslím, že je zdravý, ale netuším, jak demokraticky omezit vývoj nebo volbu (nákup) software. Nevěřím tomu, že by se to nějak "vyčistilo" - nebo někde nějaké čištění je vidět?
Spíš si myslím, že prostor pro inovace v IT se vyčerpá (horký byznys se bude dělat jinde), a situace se trochu uklidní - tak jak je to vidět například ve strojírenství, stavebnictví nebo v leteckém průmyslu. Nicméně, že by se udělal nějaký refaktoring - pochybuju, že by se mohl udělat na komerčním základě - nikdo to nezaplatí. Trochu dělám terminálové aplikace (viz pspg), to je neskutečná žumpa, a nikdo nemá odvahu nebo sílu (ať fyzickou, ekonomickou nebo morální) ji vyčistit. I u těch terminálových aplikací je dost velká režie (díky abstrakci - ncurses nebo termcap, terminfo). Každý znak, který se zobrazí v terminálu se několikrát překódovává. Zpětná kompatibilita je neskutečná koule na noze, a reálná zkušenost ukazuje, že firmy nebo produkty, které přestaly řešit zpětnou kompatibilitu, tak neuspěli. Takže se řeší zpětná kompatibilita, ale výsledek vidíme. Podívejte se třeba na WIN API. K jedné funkci existuje 10 verzí - a že by na trhu prorazil některý z nových slibovaných systémů od Microsoftu nebo Google, to není vidět, a nemyslím si, že je reálné to očekávat.
-
Postupný vývoj je vlastně i díky vývoji hw. Silnější železo vám otevírá možnosti, které dřív nebyly - mění se bottlenecky. Na starých CPU byla možná jen kompilace, interpretace byla opravdu pomalá, na novějších už i interpretace byla docela rychlá, a pokud máte dost paměti a moderní CPU, tak už je možná JIT, ale to už je opravdu hodně náročné na zdroje. Takže ona nedá úplně jednoduše říct, že nový hw využíváme neefektivně, protože ho dost často využíváme jinak než starý hw.
