avanceret batterioptimeringssoftware
Det er sjovt, at virksomheder altid skal gøre tingene kompliceret. I princippet, er batterioptimeringssoftware ikke andet, end det vi alle gør, og kun nødvendigt, fordi det ikke blev gjort først: Nemligt, at slukke for strømmen, når vi ikke har brug for den. Præcis, som at slukke for pærene i huset, når vi ikke har brug for lys. Førhen, var det en selvfølge, men efter alt det her med lavenergipærer osv. så lærer de unge ingeniører ikke den slags. Det kaldes så "avanceret", og bygges på bagefter.
Det som er lidt svært, i forbindelse med minimering af strømforbruget, har intet med batterioptimering at gøre, men noget med hastighedsoptimering at gøre: Det er vigtigt, at anvende nogle hurtige algorithmer, der bruger få indstruktioner, for at løse en opgave. Mest vigtigt, er at bruge algorithmer, hvor der ikke sløses med store O. Dertil, kommer effektiv kodning, så at operationen går hurtig (ikke ved parallelisering), og endeligt så eventuelt en optimering af lille-O, hvilket afhænger mest af den pågældende compiler. Der kan nemt være en forskel to, afhængigt af hvor gode de er til registeroptimeringer, og andre optimeringer. Brugen af cache, kan også betyde meget - f.eks. hvad der er inderst i et opslag. Stak tjek, og andre tjeks, skal helst være off - det kan nemt betyde 10% - 20% i forskel på forbruget, specielt hvis compileren har det med at kalde funktioner for hvadsomhelst. Nogle gør det altid i OOP, fremfor at tildele variable direkte værdi, og har ikke indvesteret i en compiler, der selv omskriver koden, eller valgt at tildele værdierne, og så omkode tildelingen, hvor tildelingen af en værdi, ønskes gjort som funktion. Hvis funktioner således kaldes, for enhver opsætning, kan staktjek nemt udgøre 20% af indstruktionsforbruget. Hvis compileren direkte kan indsætte kode, når det er små rutiner, så vil det spare masser af strøm fordi der ikke springes i koden. Compilerens optimeringer er altså afgørende, for et lavt strømforbrug.
Når programmet er optimeret, til at udføre tingene så hurtigt som muligt, ved at bruge så få indstruktioner som muligt, så vil energiforbruget være lavt, såfremt at processoren går i power-down, eller sleep-mode, når at den intet laver. I praksis, betyder det, at computeren ingen strømforbrug har, med mindre der trykkes en tast, eller flyttes på musen. I mange tilfælde, vil gammelt software, hvor der blev gjort noget ud af at optimere, og de metoder som blev brugt tidligere, medføre et lavere strømforbrug, såfremt processoren også slukker, når den intet laver. Den vågner så, når musen flyttes, eller der trykkes en tast.
Begrundelsen for, at idag kode så effektivt som muligt, er ikke hastighed som det var i gamle dage - det er derimod forbrug af strøm. Bruges 30% færre maskinkodeindstruktioner, holder batteriet 30% længere per opladning. Det betyder, at der kan være stor forskel på compilere, og selv det at slå stakcheck og andre checks fra, hvor det er muligt og sikkert, kan give op til 10%-20% længere batterilevetid. Cachebrugen, og eksempelvis hvad der vælges som "inderst" og "yderst" index i et array betyder en del, ligesom at compileren kan undgå spring i kode. Compileren, skal altid optimere til, at bruge cachen så lidt som mulig, og det er samme som optimering til at programmet er så hurtig som mulig. Derimod, betyder programmets størrelse ikke meget, så der skal typisk optimeres efter hastighed, og ikke størrelse.
For de fleste ældre ingeniører, er ovenstående banalt, og ikke just noget man praler af. Men alt tyder på, at ødsleriet indenfor kodning ingen ende vil tage, og idag er de mest banale selvfølgeligheder blevet til avanceret. Jeg tror, at det var gået bedre, hvis man indenfor software, havde som vane at lave datablade for sin kode, der angav eksempelvis ramforbrug, og store O funktioner, således at helt op til brugerniveau, kan angivea hvordan store O funktionen er, og hvad den afhænger af. Dataene og specifikationerne skal så tjekkes hele vejen op igennem hirakiet, så man sikrer sig, at der er den angivne sammenhæng mellem den angivne store O funktion, og det faktiske tidsforbrug, eller ramforbrug. En kode, hvor der ikke står "hvor lang tid", at koden tager, i dens data, har i princippet uendelig svartid, og svarer aldrig - trods det måske matematisk kan bevises, at "hvis" den svarer, så svarer den korrekt. Det er mindre interessant, at den svarer korrekt, og at programmet er korrekt, end at koden svarer indenfor en acceptabel tid. Uden tidsinformation, typisk angivet ved store O funktioner der kan verificeres, så må man normalt betragte programmets svar og om det nogensinde svarer, som en ren tilfældighed. I de fleste tilfælde, vil der eksistere opgaver, hvor svartiden er ekstrem, eller der aldrig svares, med mindre andet er dokumenteret. Indenfor alle andre ingeniørbrancher end software, fungerer det på den måde. Alt, som er relevant for en komponent, og også for de "komponenter" de bruges i, dokumenteres. Tid og ram, skal altid dokumenteres, da uendelig tid, og uendelig ram, ellers accepteres. Mange applikationer har idag ikke et endeligt forbrug af ram, og kan ikke modbevises at slette harddisken med data. Hvis alt er dokumenteret, vil man også kunne angive tekniske data, for det endelige program, da det så bare er at bruge komponenternes tekniske data. Eller, man kan sikre sig, at eventuelle krav, er opfyldte.
Mon ikke, at det i virkeligheden hører til i rubrikken "advances", eller "features", fremfor at være avanceret teknologi?
