A NetBSD kódhízás 20 éve

NetBSD

"A kilencvenes évek közepén kezdtem a NetBSD-vel egy Sun SPARC ELC-n 32 megabyte memóriával, ahol GCC-t és Emacs-t használtam X11-en FVWM ablakkezelővel. Még mindig GCC-t, Emacs-t és FVWM-et használok ugyanazokkal a konfigurációs fájlokkal (frissítve az Emacs-ben és FVWM-ben történt lényegtelen változásokhoz), de most már sokkal több memóriára és CPU teljesítményre van szükségem... Az gondoltam, hogy érdekes lenne kinyomozni, hogy miért..."

Krister Walfridsson blogbejegyzése itt.

( Huncraft v | 2016. 06. 05., v – 18:52 )

*2002 óta (14 éve)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( mrev | 2016. 06. 05., v – 21:13 )

Lehet, hogy érdekes lesz a nyomozás eredménye, de szerintem nem olyan nagy ez a növekedés. Ahogy látom 2-5-ös szorzóról van szó, miközben a hardver teljesítmény több százszorosára nőtt.
--
ulysses.co.hu

Tisztaban vagyok vele, hogy ha van tobb memoriad akkor azzal sok esetben tudod csokkenteni a munkat a processzorod szamara. Ez viszont nem jelenti azt, hogy ha gyorsabb processzorod van akkor elned is kell ezekkel a lehetosegekkel. A novekvo memoria hasznalatnak a novekvo memoriahoz van koze, nem pedig a novekvo processzor teljesitmenyhez.

Amugy nem zavar, hogy tobb memoriat hasznalnak a modern rendszerek. Egyreszt vannak azok az esetek amikor processzor idot nyersz vele (inlining, CPU dispatch, lookup tables), masreszt sok esetben a programozo ideje dragabb mint a memoria amit meg lehetne sporolni.

Nem a memóriamérettel van a probléma általában, hanem annak felhasználási módjával. Valamikor 2000 környékén szembesültem elöször azzal a ténnyel, hogy s memória is fragmentálódik. Már nem emlékszem kristálytisztán, de egy Compaq Proliant szerver-en futó SQL-adatbáziskezelö sírt, hogy nincs elég memóriája az akkori 64 GB-on, ami rengetegnek számított. A probléma oka valójában az volt, hogy a 64 GB-ban nem volt egyetlenegy összefüggö szabad 300 MB-nyi terület sem. Aztán valami script-tel on-the-fly defragmentálva lett a memória, és lenyugodott.
Ma is a rendszerek többsége cache-nek használja a memória nagy részét, mert általában nem futtat senki Sem annyi mindent párhuzamosan, amivel értelmesen ki lehetne használni akárcsak pl. a 8 GB-os memóriát.

A kódméret nö, ami odáig vezet, hogy pl. Ubuntu 16.04-hez kell az SSD, hogy ha megnyitsz egy Nautilus-t, kvázi azonnal megjelenjenek az ikonok az ablakban, és nem egy mp-el késöbb. Mert többmegányi minden, és idöre van szükség annak beolvasásához. Szerencsétlen processzorok idejük 99.99%-át várakozással töltik.

--
robyboy

https://en.wikipedia.org/wiki/Page_%28computer_memory%29#Huge_pages

Ez azért szomorú, mert mint a linkelt táblázat alapján valószínűsíthető, az általad használt rendszer 4K-s memória lapokat használ. Ami azt jelenti, hogy 4K fizikai memória leképezhető bármilyen lineáris címterületre. Tehát nem volt a rendszerben 300*250db érintetlen lap. Ami persze simán lehetséges, ha minden lapból csak néhány byte-ot használok ki, de nagyon elvetemülten hangzik. :) (Vagy valami teljesen más dolog van a háttérben amiről nem tudok.)

Szerk:
"Aztán valami script-tel on-the-fly defragmentálva lett a memória"
Ez azért nem lehetséges, mert a lineáris címterület van fragmentálódva, tehát konkrétan a programok által használt pointerek. Ha ezt egy script meg tudja gyógyítani, ott biztos nem az van amit én gondolok.

1. A legtobb alkalmazas nem adja vissza a kisebb egysegekben lefoglalt memoriat a rendszernek.
2. brk() val fokalt memoria nem felszbadithato az elso hasznalat utan, anon mmap -al foglalat-ak lennek az elvben felszibadithatoak (tipikusan nagyobb foglalasokra hasznalt)
3. fregmantalodas miatt bukhatod memoriad felet, ettol tobbet bukni abnormalis

4. Vannak fura DB-k furra szokasokkal, ne keres bene logikat ;)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

glibc alapbol DEFAULT_MMAP_THRESHOLD 128*1024 (byte) (minusz a foglalasi egyseg leiro) tol kisebb memoriat, nem adja vissza a rendszernek free(3) utan. Ujabb malloc(3) hivas eseten az app ujra felhasznalhatja.

Ettol nagyobb foglalasi egyseget vissza add, a rendszer `ujra keverheti` a lapokat .

(Default mukodes, elso kozelitesben)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az az sql szerver simán szar volt valamilyen okból. Ha valami bekajál 64GB ramot akkor azért jó lenne ha nem csinálna ilyeneket. Főleg, hogy valami scripttel sikerült megoldani a dolgot. Foglalgatott memóriát és direkt keveset írt egy lapba vagy ezt, hogy hozta össze?

A jol tippelt ugras is dragabb, mint nem ugrani, ill. az ugrasi feltel kezelese is jar nemi plusz utasitasal.

unroll miatti cache hasznaltnak lehetnek karos hatasai, tenyleges adatokat nem tudok.

Valamint a tobb regisztert tudsz hasznalni unroll -al, igy az utasitasok jobban parhuzmasithatoak lesznek a cpu altal.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.