mboost-dp1
unknown
#50 det er heller ikke mit argument.
Mit argument er blot at størrelseoptimering er hurtigst, så længe man ikke belaster CPU'en fuldt (da execution time så er ligegyldig).
Mit argument er blot at størrelseoptimering er hurtigst, så længe man ikke belaster CPU'en fuldt (da execution time så er ligegyldig).
Nu prøvede jeg så at compile med -Os. Det sjove er, at den der er compilet med -Os er lige så stor som den med -O2. (de er stadig begge stripped)
18324 yellow_rose_gcc2.95
18124 yellow_rose_gcc3.3
18072 yellow_rose_gcc3.4
17828 yellow_rose_gcc4.1_O2
17828 yellow_rose_gcc4.1_Os
yellow_rose yellow_rose_gcc4.1 afviger: byte 25, linje 1
Så er spørgsmålet bare om -O2'eren er hurtigere, selv om den er lige så stor som -Os.
Og bitte små skridt gør jo også en forskel, det var bare min pointe. Bare kig på #40. Det er jo også fremgang hvis de kan gøre compileren både bedre til at optimere, men også bedre til at lave små executables.
Det små skridt tager jo også tid i længden, når der er mange programmer på spil.
18324 yellow_rose_gcc2.95
18124 yellow_rose_gcc3.3
18072 yellow_rose_gcc3.4
17828 yellow_rose_gcc4.1_O2
17828 yellow_rose_gcc4.1_Os
yellow_rose yellow_rose_gcc4.1 afviger: byte 25, linje 1
Så er spørgsmålet bare om -O2'eren er hurtigere, selv om den er lige så stor som -Os.
Og bitte små skridt gør jo også en forskel, det var bare min pointe. Bare kig på #40. Det er jo også fremgang hvis de kan gøre compileren både bedre til at optimere, men også bedre til at lave små executables.
Det små skridt tager jo også tid i længden, når der er mange programmer på spil.
Da vi snakker om filer der er kompiletet forskelligt må execution time da nødvendigvis være forskellig.
Du kunne jo teste ved at kompilere to cores med hver sin metode og checke hvilken core der havde kortest startup time, men alt andet (incl. denne post) er ikke andet end spekulationer. Godnat og sov godt.
Du kunne jo teste ved at kompilere to cores med hver sin metode og checke hvilken core der havde kortest startup time, men alt andet (incl. denne post) er ikke andet end spekulationer. Godnat og sov godt.
[url=#7]#7[/url] mathiass
Jeg vil tro den primære forskel ligger i, hvornår du skal vente på at få koden compileret samt i memory management. Med en JIT compiler må du jo forvente at der går lidt tid før programmet kommer op i omdregninger. Med et program, som bliver indlæst fra disk en enkelt gang og derefter kaldt adskillige gange under opstart og hvert n'te minut mens systemet kører, vil et overhead til compilering hver gang være af stor betydning.
Noget helt andet er så memory management. Når du implementerer en java VM har du langt større frihed til at vælge memory management algoritmen, end du har ved implementation af et runtime environment til C eller C++. Og her har vi nok fat i den ubetingede største ulempe ved C og alle beslægtede sprog.
[url=#9]#9[/url] Benjamin Krogh
[url=#27]#27[/url] SmackedFly
[url=#32]#32[/url] jfs
[url=#33]#33[/url] jl
Jeg kender ikke et eneste filsystem med lige så ineffektive datastrukturer som FAT. Hvis vi skal sige noget fornuftigt om performance, så bør vi nok kigge på et andet filsystem end FAT.
Og det er ikke nødvendigvis sådan at dem i VM'er yder dårligere...En moderne VM compilerer i sidste ende til native kode, og således sammenligner vi altså performance af native kode med native kode. Om man er gået via java byte kode eller andre sprog på vejen burde ikke gøre den store forskel, hvis der bliver brugt optimerende compilere.
Jeg vil tro den primære forskel ligger i, hvornår du skal vente på at få koden compileret samt i memory management. Med en JIT compiler må du jo forvente at der går lidt tid før programmet kommer op i omdregninger. Med et program, som bliver indlæst fra disk en enkelt gang og derefter kaldt adskillige gange under opstart og hvert n'te minut mens systemet kører, vil et overhead til compilering hver gang være af stor betydning.
Noget helt andet er så memory management. Når du implementerer en java VM har du langt større frihed til at vælge memory management algoritmen, end du har ved implementation af et runtime environment til C eller C++. Og her har vi nok fat i den ubetingede største ulempe ved C og alle beslægtede sprog.
[url=#9]#9[/url] Benjamin Krogh
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å.På mange programmer vil de få bytes intet betyde, da der alligevel rundes op til et helt antal 4KB blokke på filsystems niveau. Og hvis du så alligevel skulle opnå at spare en enkelt 4KB blok på en større executable, så sparer du alligevel under 0.1ms, da harddiske nutildags overfører over 40MB/s.
[url=#27]#27[/url] SmackedFly
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.Der er ingen tvivl om, at man kan vinde noget der. Men der hvor der er noget at vinde er på søgetiderne, ikke på mængden af data, der overføres. Hvis man på forhånd ved ca. hvilke sektorer, der skal indlæses fra disken, så kan man f.eks. indlæse dem til cache i rækkefølge før man starter den egentlige boot process.
[url=#32]#32[/url] jfs
Jeg vil tro (håber?) at andre OS bruger lignende metoder.Det du beskriver minder i hvert fald om den måde Linux håndterer det på, bortset fra at i Linux er du ikke tvunget til at bruge en swap fil.
[url=#33]#33[/url] jl
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?Nu er FAT et dårligt eksempel at trække frem. FAT tabellen fungerer som en linket liste. Søgninger i en linket liste er langsomme. Selvfølgelig caches tabellen i RAM, det er det, der gør forskellem mellem langsomt og ulideligt langsomt.
Jeg kender ikke et eneste filsystem med lige så ineffektive datastrukturer som FAT. Hvis vi skal sige noget fornuftigt om performance, så bør vi nok kigge på et andet filsystem end FAT.
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