Megidézlek Hajbazer...

Mostanában kicsit felhúz idegileg Windows és Linux rendszereken is, igaz főleg utóbbin, a rendszerek/alkalmazások indokolatlanul bődületes hely és memóriahasználata. Kijött az Xubuntu 24.04 LTS, a hírben láttam a telepítő méretét, 3.8 GB az ISO. Kissé visszahőköltem a mérettől, majd ránéztem a 14.04 LTS ISO-ra, ami 930 MB. Elkapott a harctéri ideg, lehúztam a 14.04.01 LTS ISO-t, a 23.10 ISO-t, és a mostanában megjelent 24.04.01 ISO-t. Virtualboxban létrehoztam 3 egyforma virtuális gépet, 2 magos cpu, 4 GB ram, 27 GB tárhely, majd mindhárom iso-t bebootolván csináltam egy sima egypartíciós telepítést. Mindhárom képfájl az xubuntu.org-ról letöltött „eredeti” x64-es ISO.

 

14.04.01. Telepítő képfájl 0,93 GB a telepítő igényel 5,9 GB-ot telepített és frissített méret 4,1 GB, ram használat idle 7%. Telepítés eseménymentes, gyors, reboot után szól, van újabb LTS, majd miután nem kérem, csomagokat frissít. Gyors, „pici”, esztétikus. „A tökéletes linux desktop” ahogy kell.

 

23.10. Telepítő képfájl 3,0 GB, a telepítő nem ad információt a helyigényről, telepített és frissített méret 8,3 GB, ram használat idle 19%. Particionáláskor figyelmeztet az uefi partíció hiányára, a /boot hiányára egy „bios-t használó gépen”, de feltelepül.

 

24.04.01. Telepítő képfájl 3,8 GB, a telepítő nem ad információt a helyigényről, az xubuntu.org rendszerkövetelmény része minimálisan igényel 8,6, ajánl 20 GB-ot telepített méret 10 GB, ram használat idle 21%.

Manuális particionálás esetén létrehozott egy sda2-őt 1 MB mérettel kérdés/kérés nélkül. Új partíciós tábla generálása után továbbment egy partícióval. Telepítés közben az állapotjelző „csík” helyén egy pulzáló izé villog, semmi nem jelzi hol tart a telepítés. Grub-ot nem tud telepíteni, megszakad a telepítés. Az xubuntu.org a gépigény részben nem említi az uefi-t. Auto telepítés esetén létrehoz egy 1 MB-os bios boot partíciót. Simán bevágni a grub-ot az mbr-be más nem megy neki. Fejődünk, fejlődünk. Kár hogy visszafelé…

A telepítő képfájlok méret növekedésének egy részét megmagyarázhatom a 23.10 és a 24.04-ben meglévő libreoffice, játékok, stb megjelenítésével, bár megjegyezném, a LibreOffice_24.8.0_Linux_x86-64_deb.tar.gz mérete 200 MB, nyelvi csomagokkal együtt 205 MB.

Azonban akkor is azt kell mondanom, 10 év alatt a telepítő mérete megháromszorozódott, a memória használat megháromszorozódott, a használhatóság viszont nem javult, sőt rosszabb lett. Azt már nem is említem, hogy „természetesen” a 24.04.01. telepítése 3x annyi ideig tartott mint a 14.04.01.-é.

 

„régen minden jobb vót”

( kleinie | 2024. 08. 31., szo – 16:33 )

Valaminek hajtani kell a hardver fejlesztést és az elavultatást...

( Ebcsont | 2024. 08. 31., szo – 16:52 )

No ezért nem használok a 10.04 óta semmilyen buntut. Utóbbi pár évben a Debianban is látni vélem ezt a jelenséget, bár ennél lényegesen enyhébb formában.

( akkos v | 2024. 08. 31., szo – 18:44 )

ezt a picsogást az időben bármelyik irányban kiterjesztheted. '14-ben is ugyan ezzel volt tele a hup, hogy bloat minden. '34-ben is ugyan ez lesz, hogy bezzek 10 éve elég volt a 16giga ram. :D
Persze lehet mondani mindenfélét, hogy bezzeg a mai fiatalok/fejlesztők/r1userek/ vagy más tetszés szerinti hibáztatandó alanyt. De a legtöbb esetben csak arról van szó, hogy nem fogadjuk el hogy a világ megy a maga útján, mi meg beleragadunk az általunk legjobbnak itélt korba. Amúgy köszi, nem szeretnék 2014-es linux distrót használni, volt azoknak elég bajuk, footprint ide vagy oda. Maximum azóta nem lettek számodra_hasznos új feature-ök.

Amit pedig mindenki elfelejt (te is) a picsogás általánosítása és a laggard címke felragasztgatása közben, az az hogy mennyiben használjuk más célokra, feladatokra a számítógépet most, mint 2014-ben. Semennyiben. Ugyanakkor, ahogy mész vissza az időben, fogsz találni egy pontot, ahol ezek a különbségek elkezdenek kipotyogni az összehasonlításokból. Például 2004 és 1994 között már elég nagy különbségek lesznek (Internet, multimédia, 3D stb.).

mi meg beleragadunk az általunk legjobbnak itélt korba

Akkor ragadunk bele, ha silányodik a rendszer. A bloat-osodás, a hízás is egyfajta silányodás. Persze, hogy ragaszkodni fogunk a régebbihez, ha az jobb azokból a szempontokból, amik számunkra fontosak.

Maximum azóta nem lettek számodra_hasznos új feature-ök.

Igen, végül is, mindig a tükör hibás™, ha az arcod ronda. :P Még meg is állná a helyét, ha 3x annyi feature lenne ezekben a Linuxokban, de nincs annyi, sőt számos hasznos feature-t inkább kiszedtek belőle, nehogy a haladó felhasználó hatékonyabban tudjon dolgozni, mint az előző rendszerén, tapicskoló digitális konzumidióták értelmi szintjére süllyesztették, csiligány, animációbuzi, tabletbuzi, óvodás kezelőfelületekkel. Akkor legalább harmadolták volna el a méretét háromszoros hízás helyett, de nem: meghízott és elsilányodott.

"mennyiben használjuk más célokra, feladatokra a számítógépet most, mint 2014-ben"

Te biztosan nem, de más esetében ez nagyon nem így van... tíz éve ssh+böngésző+rdp oszt' jónapot a desktop-on. Mostanság ezen felül VM-ben fut Linux és/vagy Windows, buildelek osm térképeket, olyan statisztikákat, adatfeldolgozásokat csinálok, amiket 10+ éve szerveren "majd elkészül" módon lehetett megoldani...

És az, hogy a full telepítő mekkora az csak egy mérőszám, kérdés, hogy hány csomag, hány új elem/funkció került bele? Ami kikerült az egyes verziókból, az döntően azért történt, mert vagy az upstream "dobta" a fejlesztést, vagy a karbantartó "fogyott el", vagy egyszerűen minimális számú igény volt rá.

Ilyen alapon a ~ 30 éves SLS disztróhoz viszonyítva (30 vagy 40 darab flopi, azaz bőven számolva 56MB) minden _is_ bloat... 

 

Te biztosan nem, de más esetében ez nagyon nem így van...

Szokásos semmitmondó lózung. Ettől nem lesz igazad.

tíz éve ssh+böngésző+rdp oszt' jónapot a desktop-on.

Nem mondtam, hogy csak ezek, de ezek is mentek 2014-ben és mennek most is.

Mostanság ezen felül VM-ben fut Linux és/vagy Windows, buildelek osm térképeket

2014-ben is pontosan ugyanúgy ment a lokális VM-ezés, ahogy most megy. Csak ugye akkoriban a VM image-ek harmadakkorák voltak és fele annyi memóriát se zabáltak és pont ez lenne a lényeg, amit meg kéne értened. :P

Pontosan ugyanúgy, ugyanazokkal a célokkal lehetett VM-ezni egy 2014-es Ivy Bridge gépen, pláne, hogy az első olyan Intel generáció, ami már támogat natívan 32 GB RAM-ot.

Ja még mielőtt elfelejtem: Ismét gyönyörűszépen hoztad a rétegigényeid, csak tudod, ez nem validálja az Ubuntu 10 év alatt háromszorosára hízását.

olyan statisztikákat, adatfeldolgozásokat csinálok, amiket 10+ éve szerveren "majd elkészül" módon lehetett megoldani...

Sajnálom, ha elzabálták előled az ESXi erőforrást, azt még inkább, ha szarul-húgyul összetákolt, alulméretezett szervereken kellett dolgoznod. Sajnos ez sem validálja az Ubuntu 10 év alatt háromszorosára hízását.

Ilyen alapon a ~ 30 éves SLS disztróhoz viszonyítva (30 vagy 40 darab flopi, azaz bőven számolva 56MB) minden _is_ bloat... 

Nem. Nem értetted meg a viszonyítás alapját. A viszonyítás alapja az volt, hogy 2014-ben pontosan ugyanarra használtunk (de legalább is használhattunk) egy desktop gépet egy Ubuntuval telepítve, mint 2024-ben. Abban igazad is van, hogy 30 éves viszonylatban ez már nem állja meg a helyét. Ugyanakkor, 10 éves viszonylatban az ég világon semmi nem indokolja ezt a bloat-ot.

"És az, hogy a full telepítő mekkora az csak egy mérőszám, kérdés, hogy hány csomag, hány új elem/funkció került bele? "

Ez is lényeges lenne ugye... Meg az, hogy mondjuk egy Office csomagban, vagy épp a GIMP-ben mennyi funkció van implementálva... Vagy mondjuk a python előretörésével hány új python csomag került bele a telepítőbe, de említhetném a linux-firmware csomagot is, ami valóban nagyott tudott nőni, és folyamatosan hízik - igaz, a támogatott hardverek számossága sem csökken ugye...

A bloat-osodás elég régi probléma. Én még az 1990-es Mikrovilágban olvastam róla, hogy már évtizede fennálló jelenség. 1994 körül 4MB-os, 16 MHz-es gépen tudtam Linuxot futtatni, X-Window felülettel. És ez a gép natív operációs rendszeréhez képest iszonyatosan lomha volt! Hol vagyunk már ettől.

Nem tudsz a bloat ellen semmit tenni, max. az igényednek megfelelő, kompromisszumos (támogatottság, security) szoftvereket használni. Ha sok időd és/vagy kevés pénzed van, akkor lehet keresgélni a nem elfuserált szoftvereket. Vagy írni sajátot a mai vasakra. Annak azért örülök, hogy a konzumer bóvli áttevődött mobil platformra, mert ott legalább az akkuidőre figyelni kell.

Nem tudsz a bloat ellen semmit tenni, max. az igényednek megfelelő, kompromisszumos (támogatottság, security) szoftvereket használni.

Ezt teszem. :)

Annak azért örülök, hogy a konzumer bóvli áttevődött mobil platformra, mert ott legalább az akkuidőre figyelni kell.

Én azért nem örülök neki, mert ahhoz képest, hogy átkerült, rendkívül sok szarul-húgyul összetákolt mocsok visszaszivárog a PC-világba. Akárcsak ha az érintőképernyő-idealizmust nézzük. Továbbá, azért sem örülök beki, mert bár nincs okostelefonom, de az a bloat, amit a mai okostelefonok megkapnak a frissítésekben egyértelműen hozzájárul egy tökéletesen fenntarthatatlan és környezetszennyező trendhez, mégpedig az okostelefonok kétévente való lecseréléséhez.

( asm v | 2024. 08. 31., szo – 19:09 )

A memoria hasznalat eseten a block device cache nelkuli erteket kellene osszehasonlitani.

A tarhelynek nem tesz jot a snap/flatpak/stb. kontenerizacio, mert minden nagy app hozza a kulonbozo libjeit (100+MB). Lehet hogy konnyebb a karbantartonak, de a usereknek kevesbe. A csomag karbantartoknak pont ezt a shortcutot nem kellene folytatniuk.

Mindhárom esetben ugyanúgy néztem memóriahasználatot, megnyitottam a "feladatkezelőt" és az kiírja hány % memória használt. Szándékosan nem egy top-ot néztem terminálban, nem a MB érdekelt feltétlen, hanem az arány különbség, ami nagyon jól látszik.

A snap/flatpack/stb. konterizációt pedig elhibázott iránynak tartom, én magam nem használom.

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. /  "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

( willy v | 2024. 08. 31., szo – 20:31 )

ram használat idle 19%.

Innen azért sejthető, hogy mindegy mit válaszol akárki is :)  

( Nyosigomboc v | 2024. 08. 31., szo – 22:03 )

10-15 eve meg volt par CD, emiatt a telepito image-et probaltak olyan meret (7-800MB) korul tartani. Aztan elkezdett felhizni, de 2014-ben meg ugy tunik, nem nagyon. Aztan ahogy a CD irrelevanssa valt, elkezdett a telepito a DVD merethez/4GB-os pendrive-hoz kozeliteni, tobb csomag kerult ra defaultban, igy live modban tobbet hasznalhatsz, plusz ha telepiteskor epp nincs gyors neted, hamar felmegy a kiadaskori verzioju csomag. A netinstall/minimal iso jellemzoen nem olyan nagy a legtobb disztronal.

Persze a programok gepigenye megnott valamennyire, meg tobb is telepul. Horror! Ha szeretnel minimal telepitest, azt is meg tudod tenni. Van direkt olyan disztro, ami erre van (pl. Alpine, VM/Docker image-be, teljesen sallangmentesen).

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

Ha figyelmesen olvasnál és lenne parányi tapasztalati tudásod a konkrét témával kapcsolatban, nem írtál volna ennyi marhaságot. Ha nagyapámnak áramszedője lett volna, trolibusz lett volna, nem volt neki, nem lett...

Annyira unom a funkcionális analfabéta, gondolkodásképtelen, kényszeresen hozzáböfögőknek magyarázni, ráadásul feleslegesen:

  1. Már a 14.04.01. is 930 Mb, tehát túllépte bőven a cd méretet, dvd-re vagy pendrive-ra kellett "kiírni".
  2. Abiword és Gnumeric helyére került be a Libreoffice és 3 kártyajáték, nem a Wesnoth van az ISO-ban, semmi sem indokolja a többmint négyszeres méretű telepítőmédiát.
  3. A minimal ISO is 1.6 GB.
  4. A programok gépigénye nem megnőtt, hanem hatványozódott, jelen írás tárgya az Xubuntu ennek csak egy konkrét példája, ami szembe jött velem és felb@szott.

~15+ éve a slax nevű disztribució 185MB (a 8 cm-es CD elméleti méretkorlátja) LiveCD-n volt elérhető, KDE és Flubox DE-vel. Egy MenuetOs ráfér egy 1.44"-es floppy-ra és ez egy komplett operációs rendszer, grafikus felülettel, hálózattal, programokkal. Ma egy Xfce4-es Live rendszertelepítőjének majdnem 4 GB kell. És nem azért nyavalygok, mert nincs helyem, erőforrásom, bármim, hanem azért mert mindennel így van és ez csak egyre rosszabb lesz, egyre pocsékolóbb szoftverek jönnek létre. De felesleges magyarázni...

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. /  "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

( hajbazer v | 2024. 08. 31., szo – 22:28 )

Szerkesztve: 2024. 08. 31., szo – 22:40

Megidézlek Raynes... aki a Linux mellett érvel folyton, minden kommentjében át akar rá terelni, még azokban is, amiket nem hozzám intéz. Ő maga pedig már csak terminálban pötyög, mert herótot kapott a bloat-tól.

Ahogy a multik (Red Hat = IBM, Canonical stb.) megjelentek a desktop Linux mögött, velük együtt az "úgyis vesz majd új gépet" típusú arrogancia is megjelent. Míg Linus Torvalds azért fejlesztette a Minixet, hogy a 386-osát hatékonyabban tudja használni, addig ma egy friss Linux már nagyon kevés esetbebn alkalmas csak arra, hogy a Windows-nál erőforráshatékonyabb legyen.

Onnan tudod, hogy egy rendszer képes-e valódi fejlődésre, hogy kihízza-e a rendelkezésre álló teret. Ha kihízza, akkor nem képes valódi fejlődésre, csak növekedésre, amit a marketingosztályon fejlődésnek fognak hazudni.  Ha nem hízza ki, akkor képes valódi fejlődésre. Aki azt állítja, hogy 10 év alatt egy 200%-os méretnövekedés feltétlenül szükséges, az vagy hazudik, vagy babzsákfejlesztő.

Ahogy a multik (Red Hat = IBM, Canonical stb.) megjelentek a desktop Linux mögött, velük együtt az "úgyis vesz majd új gépet" típusú arrogancia is megjelent.

Általában véve nem szándékozom vitatkozni, csak megjegyzem, hogy ezt a kommentet egy 14 éves AMD gépről írom [1], amely RHEL-8.10-et futtat; EPEL-8-ból telepített IceWM-mel (mint "desktop környezettel"). Egyetlen xterm-et megnyitva,

echo 3 >| /proc/sys/vm/drop_caches

után a 5685 MB "total"-ból 5023 MB "free" (kb. 12%-os "idle" RAM használat).

RHEL-9-re már nem tudok áttérni, mert az megköveteli az x86-64-v2 uarch level-t, azt meg ez a processzor nem tudja. Akkor fogom a gépet lecserélni, amikor a RHEL-8 "Maintenance Support Phase"-e megszűnik (2029. május 31-én).

Ez a gép és OS tökéletesen alkalmas mindenre, ami nem a fejlesztői munkámhoz kell (munkára van modern céges gép, Fedora 40 fut rajta, de az is IceWM-mel).

Ahol én szeretnék rámutatni a másfél évtizedes visszafejlődésre, az a JavaScript teljesítménye Firefox-ban, ésvagy a youtube (igazából nem tudom elkülöníteni, melyik a nagyobb ludas; a múltkor kipróbáltam a chromium-ot, az gördülékenyebben játszotta le a youtube videókat). Konkrétan ma már a 360p youtube videók is nézhetetlenek Firefox-ban a gépemen (diavetítés!) -- és ahogy említettem, ez egy kb. másfél évtizedes, fokozatos folyamat eredménye. Miközben ezt a két videót yt-dlp-vel 140+270 formátumban [2] letöltve, és a jó öreg MPlayer-rel lejátszva, mindkét mag továbbra is 70-75%-ban alszik. Nem a géppel van baj és nem is az OS-sel, hanem a webbel.

(Én az OS-be nem számítom bele a desktop env-et, amíg szabadon megválaszthatom az utóbbit; kb. 25 éve IceWM-et használok, disztrótól függetlenül.)

[1] HP Compaq 6005 Pro Microtower PC (VN797EA), Athlon II X2 B22, 6GB RAM, amiből az integrált Radeon HD 4200 / RS880 fél gigát eszik meg

[2] mp4a.40.2 bitrate=129k samplingrate=44k + 1920x1080 30fps avc1.640028 (=h.264) bitrate~=4700k

Gondolom, a vaapi működik.

Az about:config -ban a:

media.hardware-video-decoding.force-enabled=true

engedélyezve van?

Ennek eredményeként a "HARDWARE_VIDEO_DECODING részben "user force_enabled Force enabled by pref" jelenik meg az about:support -ban.

Most próbáltam ki ezt egy appimage firefoxban, kevesebb CPU-t eszik, mint az ungoogled chromiumom. :D (10 éves AMD noti)

Eddig nem volt bekapcsolva. Most átkattintottam, újraindítottam a firefox-ot, az about:support-ban három sort látok a HARDWARE_VIDEO_DECODING-nál:

  • default | available
  • user | force_enabled | Force enabled by pref
  • runtime | unavailable | Force disabled by gfxInfo | Blocklisted; failure code FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED

A youtube-on pedig továbbra is diavetítés megy. :/ Azért köszönöm a tippet, erről a kapcsolóról nem tudtam.

( _ventura_ v | 2024. 09. 01., v – 06:48 )

„régen minden jobb vót”

Helyesebben itt:

Csóróbbak vagyunk mint 10 éve és nem telik jobb vasra picsogásnak tűnik :D

Fedora 40, Thinkpad x280

( RadikalisLajos | 2024. 09. 01., v – 07:55 )

Szerkesztve: 2024. 09. 01., v – 07:55

csak vedd be a bsd pirulat

( enpassant v | 2024. 09. 07., szo – 10:22 )

Szerkesztve: 2024. 09. 07., szo – 10:23

Akkor álljon itt egy kis ellenpélda arra, hogy mai világunkban is vannak még olyan fejlesztők, akiknek fontos a kis memóriaméret és a gyors futás.

Andrew Kelley, a Zig nyelv megalkotója, a Zig compiler-en mutatja be, hogy miként csökkenti a memória használatot, ezáltal miként nő meg a fordító sebessége: Practical Data Oriented Design (DoD)
Eleve se volt lassú, de így elérte, hogy másodpercenként 8,9 millió sor forduljon le.

Az útnak még koránt sincs vége, még vannak részei a fordítónak, amik optimalizálásra szorulnak.

Ha másért nem, arra is jó a videó, hogy praktikus tanácsokat kapjunk a gyorsabb, kisebb memóriájú programok készítéséhez.

Andrew Kelley, a Zig nyelv megalkotója, a Zig compiler-en mutatja be, hogy miként csökkenti a memória használatot, ezáltal miként nő meg a fordító sebessége: Practical Data Oriented Design (DoD)

Érdekes előadás; rávilágít, hogy a hardver mára teljesen felborította az összes eredeti jellemzőt, amelyek alapján a hagyományosnak tekinthető (imperatív) programnyelvek készültek.

Régen ez volt nagyjából:

  • harmadlagos tár (szalag): nagyon lassú
  • másodlagos tár (diszk): gyorsabb
  • processzorral számolgatás: gyorsabb
  • elsődleges tár (memória): (leg)gyorsabb

Mik voltak ennek a következményei:

  • memóriában érdemes volt gyorsítótárazni bármit (szalag helyett, diszk helyett, számolás helyett)
  • a nyelvek explicitek voltak annak tekintetében, hogy melyik szintű tárhoz férsz hozzá; nem volt zsákbamacska. A legegyszerűbb példa erre talán a file-ok kontra változók (bármilyen imperatív nyelvben lényegében, C-ben pl. változók vagy stdio)

Mi van ma ehhez képest:

  • minimum négyszintű hierarchia a memóriában (L1, L2, L3, NUMA)
  • processzorral számolgatni gyorsabb, mint main RAM-ot elérni
  • hálózatot nem is említem (tud gyorsabb lenni, mint a main RAM)
  • stb stb stb (ld. a részletes táblázatot a prezentációban 5:40-nél); a lényeg az, hogy ezek közül a szintek közül a hagyományos programozási nyelvekben ma már szinte semmi sem explicit:
    • file lehet RAM diszken
    • normál(-nak tűnő) változó lehet mmap-olva diszkről
    • SMP megközelítés a többszálú programozáshoz lényegében hazugság (a "symmetric" ma már nem áll meg)
    • memory encryption (az alaplapon külön security processor van, ami "transzparensen" kódol a processzor és a main RAM között)

Nem azzal van baj, hogy a tárolási szintek és hozzáférési sebességek tizen-huszon nagyságrendet fednek ma már le, hanem azzal, hogy ezek nem explciitek a programozási nyelvekben. Ha valaki x86_64 assembly-ben programozik, még az is hazugság, mert a mikrokód rejtett, elfedi előled, amit a processzor valójában csinál. Régen meg tudtad mondani, hogy x=1 vagy fwrite() legyen, ma nem tudod megmondani, hogy a tár-hierarchia melyik szintjét akarod használni. A processzor heurisztikái okosabbak akarnak nálad lenni, neked kell körbetáncolnod a processzort (az adat memóriában való elrendezésekor), hogy aztán a heurisztika jól teljesítsen. Szerintem ez egy katasztrófa programozói szempontból; kontrollvesztés.

Például Intel által írt nyílt forrású (edk2) firmware-ben látható rá példa, hogy lekérdezi CPUID-vel a cache hierarchiát, aztán a visszakapott méretekkel machinálva allokál tömböket a main RAM-ban, és reménykedik, hogy majd a cache hatékonyan működik.

A forráskód már nem a processzor számára íródik, a processzor (+ a compiler) meg nem azt csinálja, amit a forráskód mond neki. Ehelyett van közöttük egy (vagy kettő, három) absztrakciós réteg, és a szélekről mindenki azt a kompatibilitási réteget veszi célba. Gyors programot nem is lehet anélkül írni, hogy az ember szénné ne mérne mindent, aztán reszelgetne, és újra mérne; egyszerűen nincs statikus specifikáció az alapkomponensek teljesítményére, amivel előre lehetne tervezni.

Ld. pl. kriptográfia. Folyamatos harcot vívnak a fejlesztők a compiler-ek és processzorok gyártóival, mert nekik nem az kell, hogy valami gyors legyen, hanem az, hogy determinisztikus, konstans idejű; ne függjön a végrehajtás sebessége az adatoktól. Ld. havi-évi szinten publikált side channel attack-ok.

Az előadás által felsorolt trükkök kivétel nélkül károsak szemantikailag és a karbantarthatóság szempontjából. Azzal nem vitatkozom, hogy a gyakorlati hasznosság igazolja azokat, viszont elszomorító, hogy a hardver és a szoftver közötti szakadék ekkorára nőtt:

  • use indexes instead of pointers ("watch out for type safety", haha)
  • store booleans out-of-band (nyilván ütközik a szemantikai alapú csoportosítással, "encapsulation")
  • eliminate padding with Struct-of-Arrays (dettó)
  • mezők sorrendjének cserélgetése (dettó; a sorrendnek is van jelentése)
  • store sparse data in hash maps (dettó)
  • "encoding" approach (nekem egyfajta denormalizációnak tűnik, talán a legrosszabb az összesből; 24:56-29:52)

A logikai szervezést az ebek harmincadjára vetjük, hogy a mindenható L1-L3 cache-ek boldogok legyenek.

Sokkal frusztrálóbb ma programozni, mint 20-30 éve; nincs ellenőrzésünk szinte semmi felett. Ha a teljesítményre akarjuk kihegyezni, akkor sincsenek jó (determinisztikus) eszközeink, ha pedig a logikai tisztaságra / absztrakcióra, akkor borzasztó árat kell érte fizetni.