57 éves a Moore-törvény

Hardver

Gordon E. Moore (az Intel egyik alapítója) eredeti megállapítása szerint az integrált áramkörökben lévő tranzisztorok minden 18. hónapban (egyes források szerint 24 hónapban) megduplázódik. Moore eredeti megállapítása az Electronics Magazine 1965. április 19-i számában „Még több komponens megvalósítása az integrált áramkörökben” című írásában található ... Részletek a Wikipédia szócikkében.

( Raynes v | 2022. 04. 19., k – 18:28 )

Lassan már inkább a törvény halálának az évfordulóját kéne ünnepelni. Kb. 10 éve egyre inkább nem igaz, lassul be a fejlődés, ahogy érik el a szilikonos gyártástechnológia végét. Bár ebben pozitív is van, egyre jobban megéri a pénzt beletenni komolyabb hardverbe, mivel 10-15 évig nem avult el, legalábbis nem használhatatlanra. Mikor még a Moore-törvény igaz volt, főleg a 60-90-es években, akkor fénysebességgel avultak el a hardverek, sokszor már a boltok polcain, 1-2 éven belül majdnem teljesen használhatatlanra, szinte havonta jöttek a gyártók új technológiával, egyre gyorsabb és kevesebbet fogyasztó procikkal, új 3D-s gyorsítókkal, új API-kkal, szinte az ember nem győzte kapkodni a fejét. Némi fejlődés azért van még, nőnek a magszámok, cache, gyorsul a memória, PCIe/USB sávszélesség, jönnek egyre inkább optimalizált SoC-ok, egyre olcsóbb SBC-k, de ezek már nem rengetik meg a világot annyira. Régen még az új Windows főverziók, meg játékok voltak a mozgatórugók, de egy ideje már ez sem igaz, a MS egyre inkább nem tud újat kitalálni, így már a 11-esnél mesterségesen kellett emelni a hardverkövetelményeket, mindenféle ellenőrzés, feketelistázás bevetésével, meg a játékokat is konzolra írják, emiatt lelassult ezen a téren is a fejlődés. Ennek ellenére sok technológia olcsósodik, LED, kijelzők, DAC-ok, SSD-k, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez is sokáig igaz volt, de ma már ez is fékeződik le. Én úgy vettem észre, hogy egy szinten túl a bloatság se tud túlnőni, már hiába szenvednek a webdevek mindenféle keretrendszeres, konténerbe zárt nested virtualizációt használó pythonos, meg electronos WSL2-es szarjaikkal (tudom, ennek nincs értelme, de jól hangzik, ezért egy webdevnek cool), már nem tudnak újat kitalálni a nap alatt. Fetrengenek GPU-k által kielemzett AI mátrixokkal, meg mindennel, de már nem tudják hová nyomni a komplexitást. Azt a szintet nem lehet überelni, mikor egy sima chat/VoIP vagy markdown jegyzetelős program 200 mega, és 1+ giga memóriát eszik, és egész csokor függőség, lib, extra API kell neki. Valahogy már az OS-ek alap desktopjai sem tudnak az 1-2 giga RAM fogyasztáson túlnőni. Bár én ha annyira unatkoznék, elő tudnék hozakodni valami fain fraktál tömörítéssel, amitől ilyen 64 magos proci is letérdel, mert miért ne, esetleg extra kamu, idle ciklusokat beletenni a kódba, hogy lassabban fusson, de még ennek is van határa. Némi lassulást okoznak a hardveres procisérülékenység elleni patchek is, meg pl. a Hyper Threading / SMT letiltása, egyéb paranoid húzások.

Ez az oka, hogy pl. a MS-nak is már mesterségesen kellett feketelistázással emelni a mondvacsinált Win11 hardverkövetelményeken, mert az nem volt egy állapot, hogy az extra layer virtualizációval nyakon öntve is egy 10/10+ éves Core i-n is túl jól futott volna, ha van benne min. 8 giga RAM és egy filléres SATA SSD, kellett valami, amivel az új PC-ket el lehet adni. Régóta már a Google és a telógyártók is ezzel operálnak, hogy megvonják a szoftveres támogatást az amúgy még teljesen el nem avult, jól használható hardverre, hogy kidobassák.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nézd, sokaknak lehet én vagyok a JS mumus, de bemutatom Data-s barátomat:

  • hát te mivel foglalkozol?
  • nagy cégeknek segítek adatokat rakni egyik formátumból a másikba realtime
  • tehát a cég ugyanaz, de a kettő közt konvertálni kell?
  • valahogy úgy
  • de te egy külső tanácsadócégnek dolgozol, nem?
  • de.
  • hát akkor hogyhogy ti csináljátok meg?
  • kiadják a piszkos munkát.
  • ja, a scrum teamek tök boldogan fejlesztenek egymástól függetlenül, és ti vagytok az integrátor!
  • valahogy úgy.
  • és mivel dolgozol?
  • pythonnal.
  • akkor biztos valami modern reactor-os csoda…
  • mi az a reactor?
  • hát tudod, twisted framework…
  • neem, mi ilyeneket nem használunk.
  • akkor mit csináltok?
  • hát minden egyes függvényhívásnál fellövünk egy docker-t, amiben lefut a függvény, aztán lelőjük.
  • Te várj, ti minden függvényindításhoz indítotok egy komplett új instance-t?
  • aha
  • és mennyi az elvárt válaszidő?
  • 50msec.

na, és akkor a JS a bloated meg a memóriazabáló, az agyonoptimalizált chrome v8-cal, meg a már-már webassembly-ben futó frameworkökkel…

A JS, mint nyelv is egy borzadály. Inkonzisztens, logikátlan, ráadásul ahány VM, annyiféleképpen szar. A JS, mint nyelv, kb. mindenre is alkalmatlan és mégis mindenre is ezt akarják már használni. Ezt azt hiszem mindennél jobban megvilágítja, hogy hetente hat új keretrendszer és/vagy transpiler jelenik meg hozzá, hogy mindegy, hogy mi - vagy egy másik nyelv, vagy valami framework - de valami fedje már el előlünk a JS baromságait, ne kelljen azzal szívni...
És ez még csak a jéghegy csúcsa, mert a többi víz alatt van: az említett JS keretrendszerek. Olyan dolgokat oldanak meg sok MB-ból, amit egyébként bárminő költői túlzás nélkül meg lehetne ezredannyiból is oldani és pont olyanok, mint az a nyelv, amire épültek: inkonzisztensek és logikátlanok. És akkor egy ilyenből fut öt darab a browserben, ha kinyitsz egy "modern" weboldalt.
Ami pedig az "agyonoptimalizált" v8-at illeti, egyrészt más brózer is van a világon, másrészt meg ez az "agyonoptimalizálás" egy mítosz: a JIT miatt viszonylag gyors, azaz valójában gépi kódot futtatsz belül, nem a JS bytekódját. Ez egyrészt el is mond mindent arról, hogy mennyire lenne gyors a JS bytekód futtatása, ha így kell megoldani, másrészt meg felvet olyan kérdéseket, hogy oké, de működik az a v8 JIT minden CPU utasításkészletével? És a válasz az, hogy nem. x86-on és ARM-on működik, a többin meg vagy "működik", vagy nem működik.

Ez persze nem cáfolja a data-s eszmefuttatásodat, csak arra reflektálok, hogy kár a JS-t védeni, még akár ezzel is, mert ha relativizálsz, azt visszafele is lehet: ezzel szívsz te, meg x ezer más data scientist, a JS-sel meg az egész világ; júzerek és kóderek egyaránt.

Oldschool Computer - http://oscomp.hu

De a legtöbb iparban elterjedt használatú keretrendszer valójában nem JS, hanem TypeScript, ami (most hadd ne menjek bele a V8 belső varázslataiba) jobban fordul JIT-re és konzisztensebb is.

az API rajt JS, de a “bloat” amit egy Prime NG vagy egy react MUI, az full típusos, és egy típusos nyelven van írva.

Sajna a más brózerek egyre inkább csak papíron léteznek. 

Szóval nem, senki nem gondolja az iparban hogy mindenre IS JS-t kell használni nyelvként, olyannyira, hogy a legtöbb dolog amit futtatsz egy másik nyelven, TypeScriptben van írva, ami felett a JS csak egy amolyan legacy API-ként fut, ha így tetszik, az a scriptnyelv az amúgy típusos nyelven, JIT-re optimalizált ipari typescript rendszerek felett.

De ettől még nem natúrban fut XWindow felett, értem én, csak speciel a data-s cuccok tippre több ramot esznek, ha minden kis 100 bájtos adathoz egyesével indul egy docker instance.. szerintem.

Egyrészt ez elég erős túlzás, hogy "a legtöbb", max. egy jelentős része. Másrészt a TypeScript egy transpiling superset, amit a browser közvetlenül nem tud sem futtatni, sem a JIT-tel gépi kódra fordítani; ahhoz, hogy működjön előbb transpile-olni kell JavaScriptre, ennek megfelelően egyáltalán nem igaz, hogy a JS csak egy legacy API alatta, valójában továbbra is JS-t futtatunk, max. egy másik nyelvben írtuk meg azt a JS kódot, amit majd a browser futtat. (És ha a transpiling kliensoldali az további overhead-et eredményez.) Erről beszéltem, amikor azt mondtam, hogy "hetente hat új keretrendszer és/vagy transpiler jelenik meg hozzá, hogy mindegy, hogy mi - vagy egy másik nyelv, vagy valami framework - de valami fedje már el előlünk a JS baromságait".
Szóval de, az ipar egyre inkább a mindent is JS-ben mentalitást tolja; ennek ékes példája az pl. Electron nevű szemétdomb is, ahol már "asztali alkalmazást" írnak JS-ben - és JS-ben írják, nem TS-ben, vagy más transpile-olt nyelvben - bár valójában egy weblapot futtat az ember egy lecsupasztott Chromiumban és minden "alkalmazás" legalább 100 MB emiatt, még ha csak egy Hello World is az.

A data-s cucc meg lehet, hogy többet eszik, de mint mondtam, az érint pár embert, meg pár gépet, a JS meg mint a pestis terjed tova a neten, az okostelefonokon és a workstation-ökön is. Arról nem is beszélve, hogy azért egy data-s cucc - mégha oly pazarlóan is van megkonstruálva - akkor is nagy mennyiségű adattal dolgozik, szóval ott valahogy nem tűnik akkora overheadnak az extrém erőforrásigény, mint az, amit a webkettes ökoszisztéma mocska eredményez egy sima űrlap-alkalmazásnál is.

Oldschool Computer - http://oscomp.hu

A typescript valóban egy transpiling superset, csak mióta a Google a saját kis házi frameworkjét - angular - TS-ben írja, azóta a böngészőjük nagyon figyel arra, hogy a TS-ből fordult kód a lehető leggyorsabban fusson.

Mindenféle extra szemét megoldásokkal az is elérhető, hogy verziónként kb egyszer forduljon le a TS kód. Szóval ugyan van egy first load overhead, de utána kapsz egy típusos, gépi kódban futó alkalmazást, kb. JVM hangulatban.

A data-s cucc minden egyes gombnyomásnál, amit valaki valahol ezen böngészőkben megnyomott, elindít egy docker-t, összekonfigurálja magát a mindenféle közel se ennyire optimalizált scriptnyelveken, majd lefuttat egy db python hívást és lebontja az egészet. Ha megint megnyomom a gombot, mégegyszer.

Eközben a JS rendszer egyszer fordult, a legutóbbi verziófrissítéskor. Valójában a telefon / laptop áramfelvétele elhanyagolható ahhoz a szerverfarmhoz képest, ami ezt a minden klikkre futó pythont futtatja - előbbi akksival is megy, utóbbit az atomerőmű mellé telepítették direkt, és nem viccelek.

Én értem, hogy a JS az a te egy szál gépeden eszik 100 megát, ez meg tőled távol, de elsősorban azért eszik ennyit, mert effektív statikusan linkeli magát az Electron-hoz: ha be volna építve az OS-be (a’la iOS), akkor 1-2 mega lenne csak, így viszont olyan, mint a staroffice volt anno, az libc-ből is hozott sajátot, biztos ami biztos, a linuxomból csak a DISPLAY változó érdekelte.

A böngésző nem tudja, hogy a kapott JS-t miben írták eredetileg. Gondolom úgy értetted, hogy a kugli figyel oda nagyon, hogy a TS-ből transpile-olt kódokból hatékony gépi kódot tudjon a v8 JIT-telni. Ez mondjuk lehet, csak éppen, ha az a kód egy bloathegy, akkor tök mindegy, hogy vanilla JS-ben lapátolták össze, vagy TypeScript-ben.

Ezek az extra szemét megoldások kliensoldalon kb. nem oldanak meg semmit, hacsak nincs feltelepítve a browserbe egy TS compiler/cacheing extension, ami a legtöbb júzernél nem lesz. (Lévén ugye hiába transpile-olta át JS-re a TS kódot kliensoldalon a JS, ha az utána egy F5-től elveszik...hacsak vissza nem küldi a szervernek tárolásra, de akkor az már szerveroldali megoldás. (És milyen rohadt gány már.)) Ha szerveroldalon van a transpile, az nyilván a kliensoldalon már nem fog extra overhead-et jelenteni, de ld. 1. pont.

Én értem, hogy a data-s cucc sokkal többet fog zabálni, de az még mindig kevesebb embert érint.

A telefon / laptop áramfelvétele nem elhanyagolható a szerverfarmhoz képest - pont fordítva: a szerverfarmé elhanyagolható. Miért? Mert data-s szerverfarmból van pár darab, telefonból meg laptopból meg több milliárd. Az emberiség energiaigényének elég tetemes részét a mai okosszarok és személyi számítógépek teszik ki. A data-s szerverfarmok ebből a tortából mekkora részt kapnak?

Ez egyfelől a "nagyanyámnak kereke volna", nyilván, ha kiszerveznék a futtatókörnyezetet külső programba, akkor nem volna olyan nagy egy electronos cucc, csakhogy nincs kiszervezve. Másfelől meg az viszont már hótt mindegy, hogy a betöltendő 100 MB-os szemétfuttató környezet (1 db csupasz Electron-Chromium) az bele lett építve az OS-be programként, mert attól még külön instance-ként fog futni mind és zabálni fog. Harmadfelől ez még csak a tárhely/memóriaigény volt, a sebességről nem is beszéltünk még...és addig jó amíg nem is tesszük.

Oldschool Computer - http://oscomp.hu

Tisztázzuk: a TS nem kliensoldalon fordul, hanem van hozzá fordító, ami lefordítja egy hintekkel telipakolt javascriptre (a hint a JIT-nek szól). Ha megnyomod az F5-öt, azzal ugyanaz a js fájl fog letöltődni, és ha nem shift-f5-öt nyomtál, csak f5-öt, akkor ha checksumra ugyanaz, meg a fejléc is azt mondja, nem fog újrafordulni gépi kódra se.

nem kell feltelepíteni extensionként, ez a TS caching a chrome sajátja, a browser szinte mindig chromium, a webkit némi késéssel követi, a firefoxot meg várjuk sajnos, hogy kipusztuljon. Amúgy abban is van ugyanilyen cache, sőt, valamelyest kezeli ezeket a TS hinteket is.

nem fog kevesebb embert érinteni, csak nem direktben érinti. A telefon pont úgy van megoldva, hogy az egy userre eső áramfelvétele a bázisállomásom jelentkezzen, ne a fülednél (mert akkor megsütné az agyad), azaz hiába van kevesebb bázisállomás mint telefon, az egész sztori arról szól, hogy per telefon a bázisállomás többet fogyaszt.
 

A szerverfarmok a teljes EU fogyasztás 2.7%-át tették ki 2020-ban, a lakossági fogyasztás 28% volt, de a telefon töltése csak 2-5 kWh egy évben, míg az EU háztartási fogyasztási átlag 3.7 MWh, azaz kb. a 28 százalék egy ezrelékéért felelnek a telefonok (azaz a telefonok áramfogyasztása a szerverfarmok áramfogyasztásának egy százada, de ha azt mondjuk a cégnél is fogyaszt, egy tizede).

továbbra is azt mondom, ez a data-s izé többe kerül.

Ha az uzemelteto is ugy gondolja, hogy az o data-s izeje tobbe kerul, akkor esetleg elgondolkodik, hogy csak minden masodik hivasnal inditson uj docker instance-ot (vagy idealis esetben nagyon ritkan). Esetleg kioptimalizalja bizonyos reszeit, vagy mondjuk hagyja a userek koveteset a fenebe, es akkor az egeszre nincs is szukseg (felteve, hogy arra kellett).

Amugy a sok adattal dolgozo python libek eleg jol meg vannak irva, altalaban c-ben. Innentol mindegy, hogy azt a kodot c-bol, bash-bol vagy pythonbol hivjak-e.

A strange game. The only winning move is not to play. How about a nice game of chess?

Hát ez az, hogy ez csak akkor van, ha szerveroldali a fordítás, de nem mindig az. Vannak kliensoldali transpilerek is és nem ritkák.

Azt nem tudtam, hogy a Chrome-ban van TS cache is, de ez megint Chrome-only. Safarival, Firefox-szal mi lesz? Én nem várom, hogy kipusztuljon a róka, bármekkora trágyává is vált az elmúlt években. És ez még mindig nem teszi negligálhatóvá az 1. pontban leírtakat: ha amit írtak, maga is egy bloathegy, akkor azon semmit sem segít, hogy TS-ben lapátolták össze, főleg, ha nem is egy ilyen fog futni, hanem öt, vagy több...

Egyrészt ez EU-only statisztika. Másrészt az asztali gépeket, laptopokat nem vetted bele, csak a mobilokat. Harmadrészt nem számítottad bele azt az energiát sem, amit a szemét által megnövekedett átvitel csinál.
https://en.wikipedia.org/wiki/IT_energy_management

Computers, data centers and networks consume 10% of the world's electricity. 30% of this electricity goes to power terminal equipment (computers, mobiles and other devices), 30% goes to data centers and 40% goes to the network.

Ez alapból is 70:30 a végpont/forgalom javára a data centerrel szemben, de ugye ez a data center sem mind olyan, mint amiről te beszéltél, hiszen ebben a "mezei" szerverparkok is benne vannak, amik megint csak a JS-related fogyasztást fogják növelni pl. a transpiling miatt.

Ennek megfelelően én meg továbbra is azt mondom, hogy a data-s izé nem kerül többe. A JS egy nagyságrenddel több energiát pocsékol el, pusztán azért, mert az egész világ érintett.

Oldschool Computer - http://oscomp.hu

Hú, ez agyzsibbasztó, nem hiszem el, hogy ilyen a valóságban van. Egyébként a JS védelmében, igen bloat, de ha valaki ésszerűen használja, amire való, és nem akar mindent abban írni, meg nem gányol össze mindenféle függőséget, akkor akár még el is menne egynek, de ez sajnos nem így van. Ez már régen is fő szabály volt, hogy gányolni lehet akármiben, meg normálisabb szoftvert is írni. Mint írtam, még ezzel együtt sem nagyon nő a bloatság. Igen, nagyon durva JS-hegyek egyes weboldalakon azért extremitásig tudnak menni, de az már tényleg csak 1-2 oldal, meg extrém bug kategória, nem fő szabály, ezeket nem számítom be az általános tendenciába, ahogy a memory leakes programokat sem.

Pythonnal sem az a baj, hogy lassabb, hanem hogy eleve kisebb CLI, rendszer, matekos, segédscriptekre (pl. GIMP modulokban 1-2 effekt) találták ki, erre devek elkezdtek komplett GUI-s, reszponzív alkalmazásokat is abban írni, és ott igen, nem valami villámgyorsak. Ugyanez vonatkozik a Lispre, Lua-ra, shell scriptre, stb.-re is. Ahogy pl. anno a Fortrant, Cobolt sem arra tervezték, hogy fullos GUI alkalmazás meg office suite, stb. legyen benne írva, annak ellenére, hogy biztosan lehetséges.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( uid_4278 | 2022. 04. 19., k – 19:55 )

Ez amúgy inkább egy OKR vállalás volt, amit tudott vinni az Intel évtizedekig.