Cross: Programiranje OS-a

Imamo iste zakljuèke, jedino nam se putevi razlikuju!-:)

Mo¾e obja¹njenje?

340 NULA na kraju nekog DLL-fajla bi se èak mo¾da mogli maknuti, ili ih NE bi ni bilo da je taj DLL napisan optimalnije....

A nekad i o vrsti varijable ovisi koliko bajtova uzeti. Kompajler to ne mo¾e sam procijeniti, osim ako mu to definira¹, ili ostavi¹ default...

Mo¾da, a ima i narodna: Vuk dlaku mijenja.....

Mo¾da mo¾e npr. ako su ti bajtovi na kraju datoteke, ili drugaèije napisanim kodom...

Ne radi se samo o obiènom izbacivanju bitova, veæ o optimalnijem pisanju koda...

Nekada (samo nekada?) su se pumpali fajlovi jer su programeri bili plaæeni po liniji koda. Za¹to se to danas ne bi radilo iz nekih drugih razloga? Npr. Radi potrebe za veæim diskovima i vi¹e memorije?

Nemamo. Tvoja neopravdana mrznja i moje poneko neslaganje s politikom MS-a su dvije vrlo razlicite stvari.

--
Petar Samardzija 
projektilskiMAKNI@OVOgmail.com 
mob: +385 (0)98 470 662

Ne mozes.

Nisi tako pricao na pocetku. Nemoj se ljutiti ti pises jedno, onda te se popljuje pa mjenjas pricu, ublazujes, izmotavas se. Da si napisao kako kompajleri nisu optimizirani, ne bi bas nista rekao.

Koliko dugo ces siriti taj mit?

Zato jer je glupo. Potreba za vise mjesta je realna potreba vec godinama i nije potreban jedan napumpan OS da bi potaknuo prodaju terabajtnih diskova.

Isto je i s memorijom.

--
Petar Samardzija 
projektilskiMAKNI@OVOgmail.com 
mob: +385 (0)98 470 662

Da si malo pametniji, da.

--
Petar Samardzija 
projektilskiMAKNI@OVOgmail.com 
mob: +385 (0)98 470 662

Srao. Puno jednostavnije :)

--
Petar Samardzija 
projektilskiMAKNI@OVOgmail.com 
mob: +385 (0)98 470 662

Ne bus ti nikada shvatio da te nule kaj ti vidis u dll-u pomocu notepada nisu neko smece i da imaju svrhu.

Naravno, ali eto, htio bi vidjeti par primjera. Htio bi vidjeti primjer gdje je razlika drasticna i zamjetna, i primjer gdje prakticki nema razlike.

--
Petar Samardzija 
projektilskiMAKNI@OVOgmail.com 
mob: +385 (0)98 470 662

Dana 17.07.2013. 23:29, vaso je napisao:

Jedno predmnijeva sabotazu, drugo nespretnost/visu_silu.

Dana 18.07.2013. 00:24, vaso je napisao:

Jel to znaci da cu te do smrti morati gledati kao nekog tko lupeta o temama koje ne poznaje, trola, krade, laze i ne mijenja se ?

Vrbe se vijaju kako vjetar puse, ocekivano.

/cut/

Najveci storage consumer je multimedija. Zasto ne skaces na grlo autorima LAME-a, DIVx-a i slicnima, vaso ?

Dana 17.07.2013. 23:52, vaso je napisao:

/cut/

Nego kako bi ti to nazvao ?

Dana 17.07.2013. 23:43, vaso je napisao:

Srecom, nemas pilotsku, nespretno mijenjas napadni vektor.

Obicno od 0.125 do 8, ovisi o tradeoffima. Najcesce 1.

Dodaje svakako. Recimo debug simbole, comments section i sl. Dapace, na UN*Xoidima tipa GNU/Linux imas komandu strip(1) koja ce neke od tih dodatnih bitova maknuti i program ce raditi potpuno jednako (ali ce biti nocna mora za debugirati u slucaju potrebe).

Pa tocno to. Kako bool sadrzi informaciju velicine jednog bita, kompajler bi mogao postici minimalnu velicinu tako da stavi 8 boolova u jedan jedini byte. Dakle potrosnja 1 byte. Ono sto ce medjutim kompajler cesto napraviti (osim ako nije array boolova definiran kao PACKED, ili overrideano ponasanje kompajlera), jest da ce staviti svaki bool u jedan byte (ili jos gore, jedan word ili vise, ovisno koliko bitova ima arhitektura) jer su mu tako operacije *brze* (speed/size tradeoff).

pa recimo moze u kodu za svaku provjeru staviti samo (pseudoasm):

JMPNZ neki_bool_3, neki_label

umjesto

BITTEST neki_bool, 3 JMPNZ neki_label

Takodjer, izmjena jedne bool vrijednosti nece dovesti do invalidacije data cachea za ostalih 7 vrijednosti, pa ce u vecini slucajeva takav kod biti znacajno brzi. Takodjer, na dosta arhitektura, kompajler ce umjesto bytea od 8 bitova potrositi i 16 ili 32 (ili 64) bita (iako bi bio dovoljan samo jedan!), zato jer se word-aligned pristupi izvrsavaju znacajno brze:

npr. za promijeniti bool vrijednost od 1 ili 8 bitova na lokaciji 0000102, recentni x86 32-bitni procesor ce (morati radi hardverske arhitekture, takozvani Read-Modify-Write cycle koji dosta ubrzava rad procesora s memorijom) procitati lokacije 0000100-0000103, napraviti [AND mask]+[OR value] replace za lokaciju 0000102, te ponovo zapisati lokacije 0000100-0000103.

Medjutim, ako je bool 32bitni na aligned lokaciji 0000104, procesor ce morati samo zapisati lokacije 0000104-0000107, sto je oko tri puta brze (jer ima oko 3 puta manje posla)

I eto ti utjecaja - potrosena 32 bita umjesto samo 1 koliko je bilo minimalno potrebno, ili ti preko 96% bacenog memorijskog mjesta!

Nda, kompajleri obicno nece sloziti tako kratak kod kao sto to moze domisljat covjek napraviti u assembleru, ali pogotovo u svijetu naprednijih procesora ce dosta cesto napraviti BRZI kod od bilo koga osim najnaprednijih programera.

Npr. moderni x86 procesora imaju multiple execution pipelines, sto znaci da ce preslagivanje instrukcija iz nekog logicnog u znacajno manje logican redoslijed omoguciti izvrsavanje neki instrukcija paralaleno.

Takodjer trivijalan primjer, pri optimizaciji za brzinu (-O2) gcc kompajler ce koristiti -funroll-loops, sto znaci da ce namjerno napraviti dupliciranje koda u ugnjezdjenim petljama

for (x = 0, x++, x < 1000) for (y = 0, y++, y

Da, ali ne jednostavno (moras i zamijeniti reference CMPW u CMPB, uz naravno readresiranje ostataka koda jer si izbacivanjem memorijske lokacije posemerio i relativno i apsolutno adresiranje) i ne bez posljedica (sporiji pristup memorijskim lokacijama)

ne bez izmjena koda, uglavnom.

Ma ima, ali dosta malo. Ne znam kako se na windozama zove objdump(8) ekvivalent, ali ce ti uz malo googlanja otkriti koje sekcije su nepotrebne. Nije sve TEXT ili DATA. Ali to je minorno u velicini.

Istinita prica je zapravo da MS namjerno dodaje nove i nove beskorisne nivoe apstrakcije koji dodaju novog i novog bloata, sto znacajno povecava kod. Naravno MS ima perfect deniability da to rade zato da bi se kod mogao lakse odrzavati, yadda, yadda, ali to ne znaci da to ne rade (i) zato da bi bio sto tezi i zahtjevao jaci hardware :)

--
Opinions above are GNU-copylefted.

Drago mi je da si to pitao :)

Jedan od meni drazih primjera:

spustanje sa 2632 byteova na 91 byte (ili jos nize do 45 ako odustanes od portabilnosti u nekom trenu :)

To je smanjenje velicine izvrsne datoteke (rezanje bloata) ZA PREKO 96% (odnosno smanjenje velicine NA ISPOD 4% originalne velicine :)

kompajlerish-bloatish...

--
Opinions above are GNU-copylefted.

Potpis, i svaka èast na poznavanju arhitekture, trudu i vremenu za ovaj post!

--
Pozdrav! 

     Tomy, 9A5ALL 

------------------------ 
http://www.hamall.com.hr