mboost-dp1
unknown
#off topic
#3 jeg er selv Gentoo bruger, og ja installationen er sku lang, og tror ikke at performance forskellen er bare i nærheden af det værd.
Men grunden til at jeg benytter Gentoo er da også systemet, der er nærmest genialt. Ved samtlige andre distributioner har jeg manglet programmer i pakke systemet, hvilket førte ud i det klassiske dependency helvede.
Gentoo klarer det hele. Findes pakken ikke i portage, eksisterer det ikke ;)
Med en Core2Duo er compile tiden nu ikke så slem. Man laver en liste og lader den stå natten over.
#On topic
Glæder mig til GCJ kommer lidt længere, lige nu er, næsten alt der har med GUI at gøre, ubrugeligt.
Kan ikke helt blive enig med mig selv om det er en god ting de ændrer på løkker der fortsætter i uendelighed.
Det er jo programmeringsfejl der burde rettes i koden i stedet.
#3 jeg er selv Gentoo bruger, og ja installationen er sku lang, og tror ikke at performance forskellen er bare i nærheden af det værd.
Men grunden til at jeg benytter Gentoo er da også systemet, der er nærmest genialt. Ved samtlige andre distributioner har jeg manglet programmer i pakke systemet, hvilket førte ud i det klassiske dependency helvede.
Gentoo klarer det hele. Findes pakken ikke i portage, eksisterer det ikke ;)
Med en Core2Duo er compile tiden nu ikke så slem. Man laver en liste og lader den stå natten over.
#On topic
Glæder mig til GCJ kommer lidt længere, lige nu er, næsten alt der har med GUI at gøre, ubrugeligt.
Kan ikke helt blive enig med mig selv om det er en god ting de ændrer på løkker der fortsætter i uendelighed.
Det er jo programmeringsfejl der burde rettes i koden i stedet.
Engelsk Wikipedia om OpenML (jeg vidste ikke hvad det var):
The OpenMP (Open Multi-Processing) is an application programming interface (API) that supports multi-platform shared memory multiprocessing programming in C/C++ and Fortran on many architectures, including Unix and Microsoft Windows platforms. It consists of a set of compiler directives, library routines, and environment variables that influence run-time behavior.
Dejligt at se at der sker noget inden for compilere. Jeg lavede en lille test (ret dårlig faktisk) den anden dag, hvor jeg prøvede at compile det samme program med de samme compiler-parametre, med forskellige versioner af GCC:
18324 yellow_rose_gcc2.95
18124 yellow_rose_gcc3.3
18072 yellow_rose_gcc3.4
17828 yellow_rose_gcc4.1
Compiler parametre var "-O2 -ffast-math -DBLKSIZE=1024 -Wall" og alle executables var stripped. Det interessante er IMHO at fremgangen (størrelse) sker i sådan nogle bitte små skridt.
The OpenMP (Open Multi-Processing) is an application programming interface (API) that supports multi-platform shared memory multiprocessing programming in C/C++ and Fortran on many architectures, including Unix and Microsoft Windows platforms. It consists of a set of compiler directives, library routines, and environment variables that influence run-time behavior.
Dejligt at se at der sker noget inden for compilere. Jeg lavede en lille test (ret dårlig faktisk) den anden dag, hvor jeg prøvede at compile det samme program med de samme compiler-parametre, med forskellige versioner af GCC:
18324 yellow_rose_gcc2.95
18124 yellow_rose_gcc3.3
18072 yellow_rose_gcc3.4
17828 yellow_rose_gcc4.1
Compiler parametre var "-O2 -ffast-math -DBLKSIZE=1024 -Wall" og alle executables var stripped. Det interessante er IMHO at fremgangen (størrelse) sker i sådan nogle bitte små skridt.
#5 om et program fylder nogle få bytes mindre har vel ikke den store betydning idag, synes det er mere interessandt hvordan den optimerer ens kode så det performer bedre / udnytter ens resourcer bedre.
Det sagt er jeg ikke imponeret over runtimes der æder en masse hukomelse, f.eks et helloworld java/c# prog der bruger 20MB ram på at gøre næsten nada.
Det sagt er jeg ikke imponeret over runtimes der æder en masse hukomelse, f.eks et helloworld java/c# prog der bruger 20MB ram på at gøre næsten nada.
f.eks et helloworld java/c# prog der bruger 20MB ram på at gøre næsten nada.Vi har diskuteret det der en del gange før. Jeg vil bare lige henvise til sidste gang, vi gjorde det. Det samme som jeg har skrevet der om java, holder for C#. Du kan ikke sammenligne programmer der kører i VM'er med programmer der kører uden. Og det er ikke nødvendigvis sådan at dem i VM'er yder dårligere...
#1
så er det tid til distcc når alle pakkerne skal recompiles :D
#4
Jeg ville ønske den havde alle pakkerne, men det er desværre ikke alt den har, det er dog meget tæt på.
-mtune=generic can now be used to generate code running well on common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel Core 2.
Jeg gad vide om distro's vil bruge -mtune=generic istedet for -march=i686.også release versioner direkte til de arch's
-mtune=native and -march=native will produce code optimized for the host architecture as detected using the cpuid instruction.
Lyder næsten for godt til at være sandt, må nok prøve det engang :)
så er det tid til distcc når alle pakkerne skal recompiles :D
#4
Gentoo klarer det hele. Findes pakken ikke i portage, eksisterer det ikke ;)
Jeg ville ønske den havde alle pakkerne, men det er desværre ikke alt den har, det er dog meget tæt på.
-mtune=generic can now be used to generate code running well on common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel Core 2.
Jeg gad vide om distro's vil bruge -mtune=generic istedet for -march=i686.også release versioner direkte til de arch's
-mtune=native and -march=native will produce code optimized for the host architecture as detected using the cpuid instruction.
Lyder næsten for godt til at være sandt, må nok prøve det engang :)
#6
Netop om et program fylder mindre har betydning. Harddiskene er idag flaskehalsen i computeren hvorfor optimering af størrelsen meget vel er den bedste måde at optimere på.
Det kan vel næsten stilles sådan op at mindre executables altid er hurtigere så længe CPU utilization er mindre en 100%.
(Jaja, groft eksempel, men se pointen i stedet for at flame eksemplet.)
om et program fylder nogle få bytes mindre har vel ikke den store betydning idag, synes det er mere interessandt hvordan den optimerer ens kode så det performer bedre / udnytter ens resourcer bedre.
Netop om et program fylder mindre har betydning. Harddiskene er idag flaskehalsen i computeren hvorfor optimering af størrelsen meget vel er den bedste måde at optimere på.
Det kan vel næsten stilles sådan op at mindre executables altid er hurtigere så længe CPU utilization er mindre en 100%.
(Jaja, groft eksempel, men se pointen i stedet for at flame eksemplet.)
#9
Ja, harddisken er ganske vist ofte flaskehalsen, men på ingen måde i denne sammenhæng.
Det spiller ind ved store mængder data processing fra disken, men når det kommer til at loade en exe fil én gang op i rammen kan de små forskelle aldrigt komme til at tage mere end ét sekund én gang.
Ja, harddisken er ganske vist ofte flaskehalsen, men på ingen måde i denne sammenhæng.
Det spiller ind ved store mængder data processing fra disken, men når det kommer til at loade en exe fil én gang op i rammen kan de små forskelle aldrigt komme til at tage mere end ét sekund én gang.
#10 Forskellene i performance er målt i ms, hvilket performance forskellen for mit eksempel også er. Ja for 1 exe fil vil det normalt ingen betydning have, men der er jo noget som boot (Om end det er relativt ukendt herinde).
Ja, når alting er lagt i ram er forskellen givetvis ikke eksisterende, og den performanceoptimerede binari er at foretrække.
Det eneste tidspunkt jeg venter på min com, er under opstart af programmer. Min Core2Duo kværner alt hurtigere end jeg kan kaste det efter den, hvorfor jeg stadig vil holde på at optimeret binary size er "hurtigst", i hvert fald opfattelsesmæssigt.
Ja, når alting er lagt i ram er forskellen givetvis ikke eksisterende, og den performanceoptimerede binari er at foretrække.
Det eneste tidspunkt jeg venter på min com, er under opstart af programmer. Min Core2Duo kværner alt hurtigere end jeg kan kaste det efter den, hvorfor jeg stadig vil holde på at optimeret binary size er "hurtigst", i hvert fald opfattelsesmæssigt.
11# Er du enig i at under opstart indlæses der max ca. 50 executables? Er du enig i at de bittesmå forskelle i størrelsen max kan tage 0.01 sekund længere?
Iøvrigt er jeg ret sikker på at loadningen af exe filen op i rammen tidsmæssigt er meget lille i forhold til hvad exe filen laver når den er loadet, og begynder at kommunikere med hardware(f.eks. harddisken), derfor er det ikke der man skal fokusere for at øge hastigheden på boot.
Iøvrigt er jeg ret sikker på at loadningen af exe filen op i rammen tidsmæssigt er meget lille i forhold til hvad exe filen laver når den er loadet, og begynder at kommunikere med hardware(f.eks. harddisken), derfor er det ikke der man skal fokusere for at øge hastigheden på boot.
Er du enig i at under opstart indlæses der max ca. 50 executables?Nej :)
Er du enig i at de bittesmå forskelle i størrelsen max kan tage 0.01 sekund længere?Nej :)
Jeg tror ikke vi bliver enige ;)
Kunne forestille mig at der kunne opstå situationer hvor en mindre executable vil være hurtigere pga. CPU cachen. Men det er blot gætteri. Nogen der ved noget om dette?
Bare af nysgerrighed: ræk lige hånden op, alle dem som bruger Fortran. Hvor mange? Jeg er udemærket bekendt med Fortrans overlegenhed mht. hastighed når det gælder rå beregninger, men stadig...
13# Hvordan vil du så forklare at det ikke er blevet standard at komprimere bytekoden, indsætte det i filen, skriv programmet til at udpakke det komprimerede i hukommelsen, og så kør det?
(Jeg er godt klar over at der eksisterer packers der gør lignende ting,som armadillo, uspack etc. men det er nu ikke pga. performance de gør det)
(Jeg er godt klar over at der eksisterer packers der gør lignende ting,som armadillo, uspack etc. men det er nu ikke pga. performance de gør det)
#12
Det er ganske enkelt IKKE korrekt. Det er bevist at Linux kan skære over halvdelen af sin boot tid væk, ved at fuldt optimere boot tiderne.
Derudover er det langt fra rigtigt at der kun loades 50 binære ekserkverbare filer, hvilket i øvrigt er irrellevant for den mængde eksekverbar data der ekserkveres, da halvdelen af opstarttiden ofte vil ligge i linkbare objekter (.so/.dll), der reelt er eksekverbart data (der dog ikke i sig selv kan ekserkveres).
#13
-Os (optimize for size) er ofte hurtigere end -O2 (2 pass optimizations afair) især hvad angår mindre programmer.
Det er ganske enkelt IKKE korrekt. Det er bevist at Linux kan skære over halvdelen af sin boot tid væk, ved at fuldt optimere boot tiderne.
Derudover er det langt fra rigtigt at der kun loades 50 binære ekserkverbare filer, hvilket i øvrigt er irrellevant for den mængde eksekverbar data der ekserkveres, da halvdelen af opstarttiden ofte vil ligge i linkbare objekter (.so/.dll), der reelt er eksekverbart data (der dog ikke i sig selv kan ekserkveres).
#13
-Os (optimize for size) er ofte hurtigere end -O2 (2 pass optimizations afair) især hvad angår mindre programmer.
16#
Huh? hvad mener du med at optimere boot tiderne? Naturligtvis bliver boottiden mindre ved at blive optimeret, men her taler jeg om hvorvidt at mindre executables konsekvent vil give lavere boot tid......
Korrekt, hvis at linkbare objekter tages med i ligningen ryger vi nok over de 50, men jeg medtog ikke dem i udregningen, da jeg opfatter det som ting der bliver gjort EFTER at executablen først er loadet op i ram, og det er netop hvad vi diskuterede.
Men du har ret i at de bør medtages i ligningen hvis man vil beregne på opstarts tid, dog mener jeg at siden det også er tilfældet med de linkbare objekter at det der tager tid er koden der bliver kørt, og ikke at det bliver læst fra disken vil det stadigtvæk holde at loadningen fra harddisken drukner i det store regnestykke, det er endda endnu mere udpræget da det kun skal loades én gang op i hukommelsen uanset hvor mange applikationder der bruger dem.
Det er ganske enkelt IKKE korrekt. Det er bevist at Linux kan skære over halvdelen af sin boot tid væk, ved at fuldt optimere boot tiderne.
Huh? hvad mener du med at optimere boot tiderne? Naturligtvis bliver boottiden mindre ved at blive optimeret, men her taler jeg om hvorvidt at mindre executables konsekvent vil give lavere boot tid......
Derudover er det langt fra rigtigt at der kun loades 50 binære ekserkverbare filer, hvilket i øvrigt er irrellevant for den mængde eksekverbar data der ekserkveres,
Korrekt, hvis at linkbare objekter tages med i ligningen ryger vi nok over de 50, men jeg medtog ikke dem i udregningen, da jeg opfatter det som ting der bliver gjort EFTER at executablen først er loadet op i ram, og det er netop hvad vi diskuterede.
Men du har ret i at de bør medtages i ligningen hvis man vil beregne på opstarts tid, dog mener jeg at siden det også er tilfældet med de linkbare objekter at det der tager tid er koden der bliver kørt, og ikke at det bliver læst fra disken vil det stadigtvæk holde at loadningen fra harddisken drukner i det store regnestykke, det er endda endnu mere udpræget da det kun skal loades én gang op i hukommelsen uanset hvor mange applikationder der bruger dem.
#21 korrekt, men jeg TROR at hvis du prøver at køre en java applikation fra en jar(zip) fil, vs en der ikke er jarret vil jar filen næppe være hurtigere til at starte op.
Jeg er under det indtryk at jar primært bliver brugt til at samle class filerne på en praktisk måde.
#22
"Men du har ret i at de bør medtages i ligningen hvis man vil beregne på opstarts tid"
Var det ikke også præcist det jeg sagde?
Jeg er under det indtryk at jar primært bliver brugt til at samle class filerne på en praktisk måde.
#22
"Men du har ret i at de bør medtages i ligningen hvis man vil beregne på opstarts tid"
Var det ikke også præcist det jeg sagde?
#4
Alt og alt er nok så meget sagt...et eller må de mangle:
Gentoo Portage:11673 (ifl. http://gentoo-portage.com/Statistics)
apt-cache stats på en debian unstable/experimental: 21294 (unikke navne så den tæller ikke dobbelt pga af en splittet system, virtuelle pakker er heller ikke med)
Selvfølgelig er Gentoo nice men brug hellere de rigtige argumenter :D (nørd appeal, open source spirit)
Let mere Ontopic så er det da rart at se forbedringer i gcc, selvom der stadig er god vej til at nå samme resultater som intels compiler. (Ja jeg ved godt de har det nemmere da deres ikke er cross platform men alligvel)
Alt og alt er nok så meget sagt...et eller må de mangle:
Gentoo Portage:11673 (ifl. http://gentoo-portage.com/Statistics)
apt-cache stats på en debian unstable/experimental: 21294 (unikke navne så den tæller ikke dobbelt pga af en splittet system, virtuelle pakker er heller ikke med)
Selvfølgelig er Gentoo nice men brug hellere de rigtige argumenter :D (nørd appeal, open source spirit)
Let mere Ontopic så er det da rart at se forbedringer i gcc, selvom der stadig er god vej til at nå samme resultater som intels compiler. (Ja jeg ved godt de har det nemmere da deres ikke er cross platform men alligvel)
#24
Ikke noget målbart ihvertfald.
De fylder alt for lidt til at betyde noget.
Man kunne også godt have samlet filerne ved at bruge et ikke
komprimerende format som tar, men man valgte altså zip format.
Jeg antager at det er for at minimere download hastighed.
Der betyder størrelse nemlig noget.
Ikke noget målbart ihvertfald.
De fylder alt for lidt til at betyde noget.
Man kunne også godt have samlet filerne ved at bruge et ikke
komprimerende format som tar, men man valgte altså zip format.
Jeg antager at det er for at minimere download hastighed.
Der betyder størrelse nemlig noget.
#17
Sorry, jeg skrev lidt for hurtigt, linux kan halvere sin boot tid, ved at optimere disk adgangen under booten, ca. 50% af tiden bruges på at vente på at ekserkverbart data bliver indlæst i hukommelsen.
Jeg tror nu stadig der bliver brugt over 50 eksekverbare filer, også foruden .so/.dll objekter, ihvertfald i linux boottid, windows ved jeg ikke nok om. Hvis du tjekker init skripts, vil du finde en fascinerende mængde binaries der bliver kaldt.
Sorry, jeg skrev lidt for hurtigt, linux kan halvere sin boot tid, ved at optimere disk adgangen under booten, ca. 50% af tiden bruges på at vente på at ekserkverbart data bliver indlæst i hukommelsen.
Jeg tror nu stadig der bliver brugt over 50 eksekverbare filer, også foruden .so/.dll objekter, ihvertfald i linux boottid, windows ved jeg ikke nok om. Hvis du tjekker init skripts, vil du finde en fascinerende mængde binaries der bliver kaldt.
27#
Aha, og hvordan udfører den så denne optimering, og hvorhenne kan jeg læse det bevis du snakker om?
Aha, og hvordan udfører den så denne optimering, og hvorhenne kan jeg læse det bevis du snakker om?
27# Og ja, ved nærmere eftertanke er der nok over 50, lad os bare sige 150, min pointe var bare at uanset hvor mange det var kommer det næppe sammenlagt over 1 sekund.
Windows er også ret slem på det punkt, services og drivers skal jo også tælles med, hvilket jeg ikke gjorde da jeg kastede tallet ud.
Windows er også ret slem på det punkt, services og drivers skal jo også tælles med, hvilket jeg ikke gjorde da jeg kastede tallet ud.
#28,#29,#30
Læs de her:
http://lkml.org/lkml/2006/5/15/46
http://lkml.org/lkml/2006/5/15/60
Jeg kan se jeg ikke huskede rigtigt med 50%, mente det var mere, min fejl, men forskellen var 12 sec, hvilket indikerer at data mængden (men dog nok især søgetiden) er meget vigtig.
Læs de her:
http://lkml.org/lkml/2006/5/15/46
http://lkml.org/lkml/2006/5/15/60
Jeg kan se jeg ikke huskede rigtigt med 50%, mente det var mere, min fejl, men forskellen var 12 sec, hvilket indikerer at data mængden (men dog nok især søgetiden) er meget vigtig.
#15
Fordi det er ineffektivt i et moderne virtual memory OS. Jeg kan i hvert fald fortælle at for almindelige ikke-pakkede binære filer laver NT kernen en mapping (copy-on-write) af den eksekverbare kode ind i virtuel hukommelse og lader VM systemet håndtere loading fra disk. Sagt på en anden måde bliver EXE filen (eller DLL'en eller hvad du nu har fat i) så at sige midlertidigt en del af din pagefile sådan så du hverken bruger RAM eller pagefile på at holde kode der er paget ud. Jeg vil tro (håber?) at andre OS bruger lignende metoder.
Med en pakker til eksekverbare filer kan man ikke få de fordele, der må koden altid blive pakket ud i hukommelsen og ligge der, og måske ryge over i pagefilen.
Fordi det er ineffektivt i et moderne virtual memory OS. Jeg kan i hvert fald fortælle at for almindelige ikke-pakkede binære filer laver NT kernen en mapping (copy-on-write) af den eksekverbare kode ind i virtuel hukommelse og lader VM systemet håndtere loading fra disk. Sagt på en anden måde bliver EXE filen (eller DLL'en eller hvad du nu har fat i) så at sige midlertidigt en del af din pagefile sådan så du hverken bruger RAM eller pagefile på at holde kode der er paget ud. Jeg vil tro (håber?) at andre OS bruger lignende metoder.
Med en pakker til eksekverbare filer kan man ikke få de fordele, der må koden altid blive pakket ud i hukommelsen og ligge der, og måske ryge over i pagefilen.
31>>>Er tricket der giver den store performance boost ikke at man undgår et forholdsvist langsomt opslag i den store fattabel for hver fil der skal hentes, og dermed øger hastigheden?
#32 Nu kunne der jo kompenseres for dette i OS´et, hvis at det var tilfældet at komprimeret kode konsekvent ville være hurtige, men det er det ikke, og derfor er OS ikke designet til programmer der fungerer på den måde, jeg mener også der er andre sideeffects ved at gøre det sådan, der besværliggører optimering bla. ved dll filer da IAT ikke stemmer overens da den er pakket, men er ikke sikker.
#32 Nu kunne der jo kompenseres for dette i OS´et, hvis at det var tilfældet at komprimeret kode konsekvent ville være hurtige, men det er det ikke, og derfor er OS ikke designet til programmer der fungerer på den måde, jeg mener også der er andre sideeffects ved at gøre det sådan, der besværliggører optimering bla. ved dll filer da IAT ikke stemmer overens da den er pakket, men er ikke sikker.
#33
Fil tabellen er ubetydelig mht. performance, den bliver læst en gang når den bliver mountet og derefter synkroniseret til hukommelsen. Du laver ikke opslagene direkte på disken hver gang, du laver dem i hukommelsen og synkroniserer ændringer til disken, alt andet ville også være skørt.
Fil tabellen er ubetydelig mht. performance, den bliver læst en gang når den bliver mountet og derefter synkroniseret til hukommelsen. Du laver ikke opslagene direkte på disken hver gang, du laver dem i hukommelsen og synkroniserer ændringer til disken, alt andet ville også være skørt.
#33 Nu tænker jeg mere på opslaget i selve fatten, ikke selve indlæsningen af den, er udmærket klar over at den bliver cached og ikke hele tiden skal læses igen.
Men såvidt jeg forstår artiklen er dets virkemåde at den gemmer de nødvendige filer liniært,efter hvilken rækkefølge der er brug for dataen, så den kan nøjes med et hurtigt opslag i en array lignende datastuktur, istedet for at den hele tiden skal slå adresser op i et b-tree.
Men såvidt jeg forstår artiklen er dets virkemåde at den gemmer de nødvendige filer liniært,efter hvilken rækkefølge der er brug for dataen, så den kan nøjes med et hurtigt opslag i en array lignende datastuktur, istedet for at den hele tiden skal slå adresser op i et b-tree.
#36
Jo, men det kommer du for såvidt heller ikke uden om med den her løsning, tabellen skal om alle omstændigheder læses før systemet kan tages i brug, og da det knap tager et sekund at mounte et ext3 filsystem er det næppe problemet.
Ideen her er, at den data der åbnes under start af systemet, ligges ned på en alternativ partition (eller et loopback filsystem) i rigtig rækkefølge, så du dels undgår søgninger og dels kan hente dataen ind i hukommelsen før den skal bruges og derved slipper for at skulle vente på at filerne hentes fra disken, og istedet hente dem fra hukommelsen.
Men det har helt sikkert mere med søgetid at gøre, end store binære filer...
Jo, men det kommer du for såvidt heller ikke uden om med den her løsning, tabellen skal om alle omstændigheder læses før systemet kan tages i brug, og da det knap tager et sekund at mounte et ext3 filsystem er det næppe problemet.
Ideen her er, at den data der åbnes under start af systemet, ligges ned på en alternativ partition (eller et loopback filsystem) i rigtig rækkefølge, så du dels undgår søgninger og dels kan hente dataen ind i hukommelsen før den skal bruges og derved slipper for at skulle vente på at filerne hentes fra disken, og istedet hente dem fra hukommelsen.
Men det har helt sikkert mere med søgetid at gøre, end store binære filer...
37# Ja, netop, søgetid! Derfor kan jeg ikke se hvordan at den artikel relaterer til hvorvidt det er forkert at jeg siger at det er ubetydeligt om en exe fil fylder lidt mere når den skal indlæses fra harddisken i forhold til boot hastighed.......
Og det kan ikke sammenlignes at cache ALLE filer i forhold til at skulle indlæse en smule ekstra
Og det kan ikke sammenlignes at cache ALLE filer i forhold til at skulle indlæse en smule ekstra
#38
Hvis du har 150 af dem? :) Men du har ret, det er relativt begrænset, jeg tror jeg fik udvidet dit argument lidt rent mentalt, det må du undskylde.
Hvis du har 150 af dem? :) Men du har ret, det er relativt begrænset, jeg tror jeg fik udvidet dit argument lidt rent mentalt, det må du undskylde.
For at retfærdiggøre mine argumenter minimalt har jeg compilet wine med -Os og -O2.
-O2: 141148 KB
-Os: 131568 KB
Altså en forskel på ~10 MB. Jeg skal altså vente på at wine loader ca. 10 MB mere fra disken i det ene tilfælde. (Forudsat at jeg bruger samtlige linier kode i wine)
For god ordens skyld har jeg lagt lister med alle executables op:
http://www.tnb.aau.dk/~bkrogh/testOs.txt
http://www.tnb.aau.dk/~bkrogh/testO2.txt
For at beregne størrelsen har jeg brugt:
http://www.tnb.aau.dk/~bkrogh/calc
Makefiles er følgende:
-O2:
http://www.tnb.aau.dk/~bkrogh/O2Make.rules
http://www.tnb.aau.dk/~bkrogh/O2Makefile
-Os:
http://www.tnb.aau.dk/~bkrogh/OsMake.rules
http://www.tnb.aau.dk/~bkrogh/OsMakefile
gcc -v:
http://www.tnb.aau.dk/~bkrogh/gcc-version
Hvis denne forskel går igen, vil jeg mene at mit argument fra tidligere holder vand: Mindre excecutables er hurtigst så længe CPU utilization er mindre end 100 %.
-O2: 141148 KB
-Os: 131568 KB
Altså en forskel på ~10 MB. Jeg skal altså vente på at wine loader ca. 10 MB mere fra disken i det ene tilfælde. (Forudsat at jeg bruger samtlige linier kode i wine)
For god ordens skyld har jeg lagt lister med alle executables op:
http://www.tnb.aau.dk/~bkrogh/testOs.txt
http://www.tnb.aau.dk/~bkrogh/testO2.txt
For at beregne størrelsen har jeg brugt:
http://www.tnb.aau.dk/~bkrogh/calc
Makefiles er følgende:
-O2:
http://www.tnb.aau.dk/~bkrogh/O2Make.rules
http://www.tnb.aau.dk/~bkrogh/O2Makefile
-Os:
http://www.tnb.aau.dk/~bkrogh/OsMake.rules
http://www.tnb.aau.dk/~bkrogh/OsMakefile
gcc -v:
http://www.tnb.aau.dk/~bkrogh/gcc-version
Hvis denne forskel går igen, vil jeg mene at mit argument fra tidligere holder vand: Mindre excecutables er hurtigst så længe CPU utilization er mindre end 100 %.
#41
1) Er det ikke flueknep? Jeg kommer med et eksempel der viser reduktion i filstørrelsen, plus fuld dokumentation på test scenarioret, og siger endda at den fulde reduktion _kun_ mærkes hvis samtlige linier kode i wine skal bruges. Skal der kun bruges 1/10 af wine for at køre et givet windows program, må man antage at reduktionen også kun er 1/10.
2) ret kort tid:
Min raptor:
$ time cat fil_på_185MB > /dev/null
real 0m2.365s
user 0m0.007s
sys 0m0.114s
Altså omkring 80 MB/s.
Hvis vi antager at vi har sparet 10 MB har jeg sparet ca 1/8 sekund.
Kan ikke se din pointe i forhold til mit slutargument i #40.
1) Er det ikke flueknep? Jeg kommer med et eksempel der viser reduktion i filstørrelsen, plus fuld dokumentation på test scenarioret, og siger endda at den fulde reduktion _kun_ mærkes hvis samtlige linier kode i wine skal bruges. Skal der kun bruges 1/10 af wine for at køre et givet windows program, må man antage at reduktionen også kun er 1/10.
2) ret kort tid:
Min raptor:
$ time cat fil_på_185MB > /dev/null
real 0m2.365s
user 0m0.007s
sys 0m0.114s
Altså omkring 80 MB/s.
Hvis vi antager at vi har sparet 10 MB har jeg sparet ca 1/8 sekund.
Kan ikke se din pointe i forhold til mit slutargument i #40.
Mener at huske fra en artikel (1999) at Microsoft dengang kompilerede for size ikke speed; mon ikke de havde tænkt/testet lidt over dette valg. Der stod vist lidt begrundelser, men de fortager sig i tågerne
#47 Mon ikke det kunne have noget at gøre med den begrænsede plads på CDer dengang?
Og jeg tvivler på at det stadigtvæk er sådan, jeg mener da jeg f.eks. støder ind i en codecaves(NOP instrukser) i microsoft software, og der er mange sikkerheds kompilerings indstillinger i deres nyeste compiler f.eks. buffer overflow protection, der ihvertfald ikke resulterer i mindre størrelser, det ville være rart hvis du kunne finde den artikel.
Og jeg tvivler på at det stadigtvæk er sådan, jeg mener da jeg f.eks. støder ind i en codecaves(NOP instrukser) i microsoft software, og der er mange sikkerheds kompilerings indstillinger i deres nyeste compiler f.eks. buffer overflow protection, der ihvertfald ikke resulterer i mindre størrelser, det ville være rart hvis du kunne finde den artikel.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund