Cross: Programiranje OS-a

Dobro! Isprièavam se u ime M$a ¹to me NISU obavijestili da su prekinuli s ranijom praksom nabijanja potrebnih resursa!...LOL

Reply to
vaso
Loading thread data ...

Pa svako malo tvrdi¹ da se ne mo¾e iz postojeæeg exe/dll-a maknuti ni jedan bajt, a mo¾e se maknuti ako se drugaèije napi¹e program....

Reply to
vaso

Kako ne? Vidi nize!

I obrnuto! Ako nema informacije koje se ponavljaju, neces mnogo dobiti kompresijom! A optimalno napisani program NEMA ponavljajuce informacije....

Reply to
vaso

Jedino za sto se mozes ispricati je za trolanje i vlastitu glupost.

--
Petar Samardzija (woobie) 
projektilskiMAKNI@OVOgmail.com 
+385 (0)98 470 662
Reply to
woobie

Jasno. Sto ti je tu cudno? Drugacije pisan program uvjetuje da je sam exe ili dll potpuno drugaciji a ne da u postjecem mozes micati nepotrebne namjerno stavljen bitove.

Nekaj s tobom gadno ne stima.

--
Petar Samardzija (woobie) 
projektilskiMAKNI@OVOgmail.com 
+385 (0)98 470 662
Reply to
woobie

Ne. Vidi nize.

Mozda tebi vizualno nema, ali za kompresijske algoritme ima. Nitko tko pise program ne mozes ga pisati na nacin na koji kompresijski algoritmi rade jer je to *nemoguce*.

--
Petar Samardzija (woobie) 
projektilskiMAKNI@OVOgmail.com 
+385 (0)98 470 662
Reply to
woobie

Tako je! Potpuno drugaèiji, maknut je 'vi¹ak' bitova!-:)

Reply to
vaso

Ne samo visak bitova, nego je potpuno novi fajl!

Kaj, vrtit cemo se stalno tako u krug? Gle, ak si takav debil, onda slobodno i dalje budi uvjeren da mozes u samom dll-u i exe-u micati viskove i gotovo...

--
Petar Samardzija (woobie) 
projektilskiMAKNI@OVOgmail.com 
+385 (0)98 470 662
Reply to
woobie

Tako je! Novi fajl bez 'vi¹ka' bitova....

Reply to
vaso

dao sam ti ja bas malo prije primjer optimalnog asembleskog koda, a koji se moze dobro komprimirati. Samo savrseno slucajan niz brojeva se ne moze komprimirati (visoka entropija), a masinski kod po definiciji nije

*slucajan* nego sadrzi nizove instrukcija kojih ima ogranicen broj i ne pristupa slucajno po memoriji nego odredjenim memorijskim lokacijama koje se onda ponavljaju (jer kod radi nesto korisno), sukladno tome, i u najoptimalnijem masinskom kodu koji ista radi ce nuzno biti ponavljanja (sto opcodova masinskih instrukcija, sto adresa memorijskih lokacija itd) pa ce se isti moci prilicno dobro komprimirati.
--
Opinions above are GNU-copylefted.
Reply to
Matija Nalis

Ovo je doduse sasvim tocno.

Dodatni nivoi apstrakcije zaista dovode do velikog code bloata i znacajnog rasta i usporavanja aplikacija, sto moze ustvrditi svatko tko je u tom podrucju barem par godina.

S druge strane, danas programer moze napisti za jedno popodne aplikaciju za koju bi mu pred 30ak godina trebalo bar 3 mjeseca posla, jer ima milijardu komponenti, widgeta, APIa i slicnog koji odrade 98% njegovog posla bez da mora prstom mrdnuti. Naravno, cijena toga je visa razina apstrakcije (da bi se pokrilo vise slucajeva), sto je po samoj definiciji neoptimiziranost.

Postoji (polu)sala u perl svijetu, da ako smatras da trebas napisati bilo kakav komad koda duzi od onelinera, da nisi dovoljno dobro pogledao na

formatting link
jer je sigurno vec napisan modul (ili par njih) koji vec radi sve to sto tebi treba :)

--
Opinions above are GNU-copylefted.
Reply to
Matija Nalis

Samo ako je kod savrsen i nema niti jedan bug i ne zelis nikada dobiti upotrebljiv bug report koji ce ti pomoci da bug ispravis.

Jesmo :) Doduse, izgleda da je problem u terminologiji - ti "optimiziranjem" smatras izgleda samo "optimiziranje za VELICINU" ("-Os" u gcc(1) opcijama) dok neki drugi smatraju "optimiziranje za BRZINU IZVRSAVANJA" ("-O3" u gccu recimo).

Primjeti da, suprotno laickom vjerovanju, "manja valicina" ne znaci nuzno "brze izvrsavanje" - dapace cesto su dijametralno suprotni - MANJI kod ce nerijetko znaciti SPORIJE izvrsavanje (vidi npr. "-funroll-loops", "-falign-*", "-fprefetch-loop-arrays", "-freorder-blocks" i sl. na

formatting link
)

--
Opinions above are GNU-copylefted.
Reply to
Matija Nalis

Funkcija ide u neki object file (".o" na UN*Xodima, ili ".obj" na MSDOS baziranim stvarima pa valjda i na windozama - nizam gledao zadnjih desetljeca :). Vise object fileova ide u library file (".a", ili ".lib" u MSDOS speaku za jednostavnija staticka linkanja koja su nam tu uglavnom bitna, APIji i ".so" / ".dll" za shared librarye je nesto drugaciji).

Kompajler kada kompajlira, vidi koji simboli su referencirani, i iz librarya povuce objekt fileove u kojima su ti simboli definirani. Oni koji nisu referencirani ("dead code") nece biti povuceni u executable, pa ce potpuno automatski, bez ikakve akcije programera biti izbaceni iz executablea...

Da bi se obrisali iz sourcea, treba barem neka poluautomatska akcija (barem ja ne bih nikad prepustio automatici da odluci kada ce obrisati dio koda :)

--
Opinions above are GNU-copylefted.
Reply to
Matija Nalis

Ako stavis checkbox na "compress disk" (ili kako se to vec zove u recentnim windozama), brijem da i hoce. [1]

[1]
formatting link
--
Opinions above are GNU-copylefted.
Reply to
Matija Nalis

Ako ti kazes. Ja ih ne koristim, ali nesto sam cuo da ljudi mnogo nisu voljeli ME i Vistu, a dosta ih nije bilo sretno ni sa win7 novotarijama.

Ovo stoji. Ili barem, ogromna vecina programera se slaze da je tocno. Bloat je s druge strane ogroman. Recentni office navodno zahtjeva par GB diska, windoze jos 10ak GB? 15GB recimo ukupno?

Sjecam se kada je operativni sistem (MS-DOS 3.3) i WordStar cijeli stao na jednu 360KB disketu, i jos ti je na njoj ostalo mjesta da napises cijeli diplomski. Govorimo o 1/3 jednog megabytea. Ovo sada je preko 30000 vece.

Istina, je nesto ljepse izgledajuce, i ima par (i duplo cak) mogucnosti vise (iako si u WSu uredno imao stvari tipa headeri, identanje, brojac strana, fusnote i ostale manje i vise napredne stvari koje bi i danas zadovoljile

95%+ slucajeva).

Ali za duplo vise mogucnosti (ma recimo i 10 puta vise mogucnosti da budemo darezljivi, iako je to pretjerivanje) imam stvar koja je 3000000% veca?!

3 MILIJUNA POSTO VECA (ili 30 tisuca PUTA, ili 4 REDA VELICINE, ili 3*10^4 PUTA)?

"Isplativost" je stvar ekonomije nazalost, jer sa engineering stanovista je to strahota. Zamisli da ti je auto pred 40 godina trosio 10L/100km, a da ti danas trosi 300 TISUCA LITARA na 100km? Bez obzira ako bi cijena benzina pala da ti to i dalje bude isplativo (iako je udobnost auta napredovola podjednako kao i udobnost office alata, recimo), jel ti ne bi bilo malo ruzno vozit toliku cisternu umjesto osobnog automobila?!

Ne, nisam specificnu za carinu, iako sam pisao razne za duty freeeve, konsignacijske prodaje i sl. I to na znacajno zastarjeli nacin od pred par desetljeca. Da, znam da je trebalo znacajno vise vremena za to isprogramirati, nego sto danas treba za "izklikati".

Sve to stoji. Samo me (kao programera) boli koliki je nesrazmjer napretka i njegove "cijene" tj. racunalnih resursa (na ustrb napretka).

--
Opinions above are GNU-copylefted.
Reply to
Matija Nalis

Hvala, mnogo jasnije! Btw: Da li kompajler nekako oznaèava 'dead code' objekte?

Reply to
vaso

Sla¾em se uglavnom! Naime, ja sam mu postavio jednostavan problem: Pri otvaranju nekog programa treba memoriju u nizu od recimo 340 lokacija popuniti s podatkom 0x00. Koja je razlika ( po velièini datoteke i brzini ), ako se to samo 'prekopira iz datoteke' ili popuni programskom petljom ( ili dodajem, ne¹to treæe)?

Reply to
vaso

Dana 18.07.2013. 19:03, vaso je napisao:

Ja sam dosadan, a ti neotesan, nedokazan i paranoican. Sve to vec znamo, kakve veze ima s temom ? Usput, lijepo je vidjeti kako s apsolutne uvjerenosti prelazis na 'moglo bi biti'. Jos je samo jedan korak do 'ne znam', hrabro.

Reply to
BotaniCar

Dana 19.07.2013. 04:19, vaso je napisao:

/cut

Malo truda s tvoje strane, pa ne moras tipkati uopce :)

Reply to
BotaniCar

Dana 19.07.2013. 04:32, vaso je napisao:

Ali, (namjerno) neoptimizirani sadrzaji ti zauzimaju tolio vise resursa da mi je neobjasnjivo da ne kricis na codec developere. Zbog njih tvoj

64Mb disk nije dovoljan !
Reply to
BotaniCar

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.