Softwareudviklere skal lære at spare på strømmen
more_vert
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.

Softwareudviklere skal lære at spare på strømmen

Opmærksomheden på batterilevetiden er blevet styrende for udviklingen af mobilt udstyr. Det handler ikke længere kun om, hvor hurtigt man kan få tingene til at køre, men også om hvor energieffektivt, det kan gøres.

Det fortæller professor på DTU Informatik Jan Madsen, som arbejder med indlejrede systemer.

»Softwareudviklere har traditionelt ikke været så bevidste om energiforbruget, men nu er det blevet det primære omdrejningspunkt,« siger han.

»Batterierne udvikler sig ikke så hurtigt, som vi kunne ønske os, og vi kan jo ikke længere bare sætte et stik i væggen og hente al den strøm, vi kunne tænke os,« siger Jan Madsen og peger på, at dette kræver et endnu stærkere samarbejde mellem hardware- og softwareudviklere.

Nødvendigt at kende hardwaren

»Tidligere skulle softwareudviklerne kende programmeringssprogene, men ikke nødvendigvis hardwaren. Men nu er det nødvendigt at kende hardwarearkitekturen for at kunne designe programmer, der begrænser den enkelte platforms energiforbrug,« siger Jan Madsen.

Han forklarer, at højniveau-programmeringssprog som C og Java har gjort det muligt at arbejde med software uden at kende hardwaren, som afvikler koden. Sprogene har gjort systemerne mere fleksible og arbejdsprocesserne mere effektive, men i dag er det vigtigt at tænke hele vejen rundt.

»Det er nødvendigt at kende hardwarearkitekturen for at kunne designe programmer, der begrænser den enkelte platforms energiforbrug ved f.eks. at udnytte tænd/sluk-funktioner i chippen. Her er det i dag softwareudvikleren, der kan træffe nogle vigtige beslutninger om timingen,« siger Jan Madsen.

Han tilføjer, at der er endnu mere at hente, når også sprogenes oversættere bliver energifokuserede.

»Desværre er oversætterne i høj grad optimeret mod at generere kode, som fylder lidt og afvikler hurtigt - og ikke mod at bruge så lidt strøm som muligt. Men de er muligvis på vej, for teknikkerne findes, som kan organisere bits og bytes mere effektivt, « siger han.

Jan Madsens kollega på DTU Elektro, professor Erik Bruun, har fokus på høreapparater, i hvilke strømforbruget er en afgørende faktor.

»Vi har jo ikke en stor mainframecomputer til rådighed, så det er klart, at softwareudviklerne skal vænne sig til, at tingene måske kører langsommere, end de er vant til, fordi hardwaren er optimeret mod et lavt effektforbrug,« siger han.

I virksomheden Data Respons, der arbejder med indlejrede systemer, arbejder software- og hardwarefolkene tæt sammen i udviklingen. Men udfordringen for softwarefolkene har ændret sig, fortæller udviklingschefen for hardware, Gilad Mizrahi.

»Tidligere gjaldt det om at optimere softwaren til at køre så hurtigt som muligt på relativt langsommere hardware. I dag er hardwaren derimod blevet så hurtig, at det ikke er så stor en udfordring længere. Til gengæld er energiforbruget blevet en kompleks udfordring,« siger han.

»I forhold til den teknologi, vi har i dag, er det svært at opnå store energioptimeringer udelukkende i hardwaren. Til gengæld kan man optimere softwaren til at udnytte hardwarens kræfter mere effektivt, for eksempel ved at køre systemer ved lavere clockfrekvens, når det er muligt,« siger Gilad Mizrahi.

Læs mere i den trykte udgave af Ingeniøren Elektronik:
"Algoritmer skruer op for hastighed og ned for strømforbrug"
"Stram styring sparer strøm i mobiltelefonen"
Abonnenter kan logge på og læse artiklerne HER.

sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

start med at undgå at modarbejde Operativsystemet.
eks. undgå at både OS og programmet forsøger at styre hvad der skal ligge i Ram og hvad der skal ligge en ram-fil på HDen

  • 0
  • 0

start med at undgå at modarbejde Operativsystemet.
eks. undgå at både OS og programmet forsøger at styre hvad der skal ligge i Ram og hvad der skal ligge en ram-fil på HDen

Det hedder "Virtuel Memory", det er snart 50 år gammelt og de fleste programmører fatter ikke en dyt af hvordan det skal bruges...

Det er en af de ting jeg prøver at skære ud i pap i mit "Varnish Performance" foredrag:

http://phk.freebsd.dk/pubs/varnish_perf.pdf

Poul-Henning

  • 0
  • 0

Det hedder "Virtuel Memory", det er snart 50 år gammelt og de fleste programmører fatter ikke en dyt af hvordan det skal bruges...

Virtual memory bruges ikke så meget i embeddede systemer, som mobiltelefoner og høreapparter. Det bruges mest i større systemer, der som minimum har harddisk eller langsom flash-rom. Men det er rigtigt, at et OS der ikke er lavet til at spare strøm, kan æde resourcerne op. Og det samme kan et dårligt bibliotek til compileren.

Software, der er lavet til at spare strøm, udfører kun noget, når det er grund til det. Som eksempel, vil man kun sjældent "polle" hardware - hvis en mus flyttes, eller en tast trykkes, laves et interrupt, der "vækker" processoren, og som aktiverer processen der venter på mus eller tastatur. Det betyder, at computeren ingen strøm bruger, når taster ikke trykkes, og mus ikke flyttes. Måske er der noget tidsstyret - dette vil typisk aktiveres af et ur, der laver et interrupt. Det er vigtigt, at processoren står stille, og intet laver, når det ikke er grund til det. Dertil, skal hardwaren slukkes når den ikke bruges, måske startes op et lille stykke tid før at den bruges, da analoge dele måske kræver en vis stabilisering først.

Som sædvanligt, er det dog ikke kun et spørgsmål om kodning. Det er ligeså meget et spørgsmål om analyse og design af opgaven. Som eksempel, kan protokollen for kommunikation betyde meget for, om det er muligt at lytte på så få bits som muligt, i så kort tid som muligt, og derved opnå lavest muligt strømforbrug. Skal alle bits dekrypteres og analyseres, før en "ringetone" i en mobiltelefon detekteres - så bruger det masser af strøm. Hvis derimod, at det kun er nødvendigt at tjekke en enkelt bit, på et bestemt sted, og at telefonen kan køre i standby undtagen på tidspunktet hvor bitten detekteres, så spares masser af strøm.

Interrupts på processoren, eller "ringetonebits", er ofte begrænset, og derfor deler resourcer ofte samme interrupt - det betyder, at der efter et interrupt, skal undersøges hvilken resource, der har medført interruptet. Hvis det f.eks. er en mobiltelefon, kan der være et begrænset antal ringebits - og flere telefoner end bits. Så er flere telefoner på samme bit, og det undersøges når en bit aktiveres, hvilken telefon som interruptet skal gå til, ved at læse en, eller flere ekstra bits i kommunikationen, der fortæller, eller sandsynliggør, hvilken telefon der ringes til. Fordelen er, at selvom der kun er f.eks. 100 interrupts, men 10.000 telefoner, så nedsættes aktiviteten af processoren drastisk, uden der optages for meget kommunikationsbåndbredde. Samme, hvis der anvendes færre interrupt linier, for at mindske hardwareudgifterne.

I mange tilfælde, er kommunikationsprotokoller en barriere for strømforbruget. Derfor, er også udviklet overbygninger, til f.eks. WIFI der nedsætter forbruget. Hvis ikke protokollen, og standarden, laves til lavt forbrug, med mulighed for wake-up, uden der skal læses mange data, så vil det ofte ikke være muligt at spare større strøm, alene ved at optimere i software og hardware. En ændring i protokollen - der muliggør et lavt forbrug - kombineret med anvendelsen af disse nye features, er det som mindsker forbruget.

  • 0
  • 0

Diverse:

Når man kompilerer sin kode, vil et programmeringsværktøj ofte som udgangspunkt inkludere et stort antal af biblioteker (units) uanset om disse bliver anvendt af koden eller ej, som kan forstørre en exe-fil fra fx 300 kilobyte til fx 20 megabyte. Sådant overflødigt fedt gør en applikation langsommere, som blandt andet koster strøm.

Hvis software anvender runtime-kode, er den skabt af tåber.

Hvis software har behov for at holde øje med om der sker et input fra en bruger, kan en programmør finde på at lave en løkke (loop). I stedet skal man lade softwaren forblive "død" når der intet sker, lave en funktion der bliver vækket af operativsystemet (når der sker en begivenhed). Denne måde at programmere, bør desuden anvendes alle vegne i et program når en funktion har behov for at kalde en funktion, fordi man således (via en kunstigt skabt event til operativsystemet) kan undgå meget dybe hierakier af funktioner der kalder funktioner. Jo mindre dybde, jo mindre forbrug af hukommelse ad gangen, som vil spare på strøm i en computer (fordi den kan nøjes med mindre fysisk hukommelse).

Megen helt ny software anvender fuldautomatisk alle kerner i en cpu. Dette kan være en dårlig idé, fordi det koster strøm. Den rigtige metode er at lade brugere angive om de ønsker at lade softwaren fordele sine opgaver.

Software skal kun anvende pointere(!). Denne måde at programmere, er noget som mange programmører aldrig lærer, med årsag i, at det er en lille anelse mere kompliceret end hvis man anvender variabler på tåbelige måder. Når man anvender pointere, vil et program kun anvende præcis den mængde af hukommelse som er nødvendig og rydde præcis op efter sig, og desuden vil softwaren undgå at kopiere variablers indhold imellem hinanden. Forskellen i performance kan være tusindefold, som i hvert fald også har indflydelse på strømforbrug.

Temmelig mange komplicerede typiske programmeringsopgaver kan i stedet løses med en ultrasimpel matematisk formel, en forskel som imellem lynglimt og et årti. Sådant er indlysende for dataloger (som blandt andet er matematikere), derimod ofte slet ikke fatbart for en typisk programmør. Uvidenhed om matematik iblandt programmører, koster dyrt for deres arbejsgiver, og dyrt for brugerne af de færdige resultater.

Temmelig mange typiske dele af programmeringsopgaver findes allerede på forhånd iblandt et operativsystems tusindevis af skjulte funktioner, som en programmør så vidt muligt bør anvende, fordi sådanne funktioner ofte er særdeles godt programmeret. Desværre er sådanne funktioner aldrig tilstrækkeligt beskrevet i litteratur til at programmører har let ved at forstå, årsagen til at programmører ofte genopfinder et stort antal af dybe tallerkener med ueffektive resultater. At det er sådan, skyldes muligvis at producenter af operativsystemer ønsker at sælge også applikationer dertil, og jo mere uforståeligt at operativsystemets indre funktioner er beskrevet, jo mindre konkurrence vil producenten opleve. I værste fald kan en producent af et operativsystem finde på at skjule nogle fælder i operativsystemet (eller give nogle dårlige anbefalinger med vilje), således at intetanende programmører anvender metoder der vil medføre at operativsystemet nedsætter hastigheden.

  • 0
  • 0

Når man kompilerer sin kode, vil et programmeringsværktøj ofte som udgangspunkt inkludere et stort antal af biblioteker

Forhåbentlig er platformen sat op til kun at inkludere libraries der er i brug. 20MB spild er seriøs belastning af BOM'en for en telefon, og burde blive fanget første gang man forsøgte at loade det på en telefon.

Jo mindre dybde, jo mindre forbrug af hukommelse ad gangen, som vil spare på strøm i en computer (fordi den kan nøjes med mindre fysisk hukommelse).

Her er der et trade-off du er nødt til at gøre: Det tager sidssygt meget længere tid at sende en event end det gør at kalde en funktion, hvilket betyder at der går længere tid inden du er færdig, og CPU'en kan sove. Det er i øvrigt især et problem hvis du bruger OS, siden sådan en skal være væsentlig mere fleksibel end en eller anden specialiseret micro-dispatcher.

Software skal kun anvende pointere(!)

Jeg vil lige tilføje: "...med omtanke". Man sparer muligvis noget tid på at slippe for memcpy nogle steder, men til gengæld bliver man hurtigt tilbøjelig til at lave kald til dynamisk allokering alle mulige steder, som måske ikke var nødvendige. Folk glemmer ofte at det faktisk koster en del at allokere memory.

...iblandt et operativsystems tusindevis af skjulte funktioner, som en programmør så vidt muligt bør anvende

Problemet er at på embeddede platforme er portabilitet en prioritet i kode, hvilket betyder at man undgår libraries man ikke selv har kontrol over. Jeg vil vove den påstand at embedded software har en stor del af skylden for "Not Invented Here" politik rundt omkring.

  • 0
  • 0

Sådant overflødigt fedt gør en applikation langsommere, som blandt andet koster strøm.

At fylde op i flash, eller rom, koster ikke nødvendigvis strøm. At fylde op i statisk ram, koster hellerikke strøm. Derimod, koster forbrug af dynamisk ram strøm, da en større hukommelse, kræver flere bytes der refreshes. For sprog som C++ sker dog ofte, at libraries der ikke bruges, har koder der kaldes. Det er blevet værre siden OOP blev indført. Tidligere, blev mange overflødige rutiner i bibliotekerne automatisk udeladt, fordi at der ikke var relationer til andre rutiner.

Genneralt, er ikke godt at bruge pointere, andet end hvor det er nødvendigt. Pointere, er analysemæssigt noget af det sværreste at håndtere. Pointers er en afart af index variable, og det er noget rod. Hvis du som eksempel, har en pointer til en position i lageret, som tildeles en værdi 25 - så ved du i princippet ikke hvilken addresse i lageret som destrueres. Det betyder, at der opstår låsning i koden, hvor der må ventes på at pointeren får sin værdi, før der kan fortsættes. På mange andre måder, udelukker pointere analyse af softwaren.

Skulle det vise sig, at en opgave giver mindre forbrug med pointere - så kan du nemt beskrive opgaven uden brug af pointere, og lade compileren oversætte det til brug af pointere. Derimod, er den modsatte vej umuligt. Du kan ikke lave et program, med pointere, og få compileren til at oversætte det til variable - denne vej, er svær.

Pointere, er således med til at destruere analyserbarhed af koden. For at analysere den, skal du analysere alt, som pointeren kan have som værdi - og dette er en svær analyse, da den afhænger af resultatet når programmet kører. Pointere, lader sig derfor sværre analysere statisk, end et program med kun variable.

Index variable, er et sted "midt imellem". Disse har den fordel, at det trods alt vides i hvilket range at pointeren befinder sig. Dette medfører mindre låsning.

Umiddelbart, synes det måske ligegyldigt med begreber som "låsning", der kommer fra parallel verdenen. Imidlertid, er der en vis sammenhæng mellem parallelisme og eventdrevet programmering - og ikke mindst det sidste, er vigtigt for lavt forbrug. Kan du analysere et program, således du kan se hvad der kan køre parallelt, så kan du også analysere det til "blokke" der behøves at blive kørt når der kommer et event - og dermed lavere forbrug, end hvis du skal udføre alt. Analysemetoderne ved eventdrevet programmering, og ved automatisk opdeling i parallele processer, har derfor et vist sammenhæng. Vi kan bruge det, til at gennemskue hvilke indstruktioner der aktiveres, hvis noget i koden ændres på grund af et interrupt eller event.

Endeligt, medfører pointere en langt større kode, og dermed større forbrug. Hvis f.eks. pointeren er på 32 bit, så kræves en simpel move at 64 bits læses, eller 8 bytes. Dertil kommer indstruktionsord og opslag i ram lageret, fra de to addresser, og overførsel af værdien.

Mest optimalt, er at læse data direkte fra pipelinen. Hvis eksempelvis, at vi skal bruge værdien, som blev aflagt 3 indstruktioner før - så kan vi angive, at vi ønsker værdien som stammer fra indstruktionen der blev udført 3 indstruktioner før. Dette fylder langt færre bits, end flere 32 bit pointers, og kode er uafhængig af addressebitbredder, og derfor kan bruges samme kode, uanset CPU'ens addressebus bredde.

I de fleste sammenhæng, hvor software bruger CPU-power, skyldes det delay-loop's, eller polling, hvor der ikke anvendes interrupts. Dertil, at softwaren "glemmer" at slukke for strømmen. Vi skal have oplært progammørerne til, at huske at slukke for lyset, når de forlader lokalet. Og kan de oplæres til, at tænde kaffemaskinen 20 minutter før, så kaffen står færdig når den skal bruges, så er også muligt, at de kan programmere software til analog elektronik, der kræves stabiliseret før brugen.

Din PC burde faktisk ikke lave noget lige nu. Med mindre, at du scroller skærmen, så der vises et billed der bevæger sig. Er billedet uden for skærmen, og trykkes ikke på en tast, eller på musen, så er ikke nødvendigt at den laver noget, andet end hver minut, hvor uret tæller op - og det er enda kun nødvendigt, hvis uret vises på skærmen.

  • 0
  • 0

Din PC burde faktisk ikke lave noget lige nu. Med mindre, at du scroller skærmen, så der vises et billed der bevæger sig..

Her er måske på plads at henvise til Poul Henning, og Virtual Memory. På en PC, vil processoren bruge idle tiden, til at udføre fornuftige opgaver, såsom optimering af hvad der ligger i ram lageret. En sådan optimering, giver ikke nødvendigvis bonus i forhold til energiforbrug, så på et low-power embedded system, vil normalt ikke foregå en sådan hastighedsoptimering, med mindre det er en fordel af hensyn til brugervenligheden.

  • 0
  • 0

Når man kompilerer sin kode, vil et programmeringsværktøj ofte som udgangspunkt inkludere et stort antal af biblioteker (units) uanset om disse bliver anvendt af koden eller ej, som kan forstørre en exe-fil fra fx 300 kilobyte til fx 20 megabyte. Sådant overflødigt fedt gør en applikation langsommere, som blandt andet koster strøm.

Carsten,

Bull-shit, fra ende til anden.

Applikationen bliver ikke langsommer af kode der ikke exekveres.

Det tager måsker mere tid for operativsystemet at loade applikationen, præcis som det tager længere tid at læse 100 liniers vrøvl end det tager at læse 10 liniers vrøvl.

Med et godt VM system, blive alt det unødvendige kode ikke engang læst fra disken.

Poul-Henning

  • 0
  • 0

[quote]Det hedder "Virtuel Memory", det er snart 50 år gammelt og de fleste programmører fatter ikke en dyt af hvordan det skal bruges...

Virtual memory bruges ikke så meget i embeddede systemer, som mobiltelefoner og høreapparter.
[/quote]

Høreapparater har næppe noget der blot lugter lidt af dynamisk hukommelsesallokering, og er så hårdt optimeret for strømforbrug, at de designer deres chips primært efter det kriterie, så lad os holde dem helt udenfor.

Mobiltelefoner, kører fuldt konfigurerede multiprogrammerings kerner idag, og hvis de har skyggen af en mulighed for exekvering af 3. part software, har de næsten per garanti også et VM system enablet.

iPhone & Googleophonen er indlysende dokumentation for ovenstående påstand, men tag og brug lidt tid på Symbian og du vil hurtigt opdage at "the good old days" i den grad er overstået.

Dine observationer om optimering passer desuden overhovedet ikke med det mønster der dominerer moderne software:

Den nemmeste måde at optimere for både hastighed, og effektforbrug, skrive softwaren så den løser sin opgave, og ikke spilder tiden på alt muligt ligegyldigt fims, den ikke har brug for at udføre.

Mit klassiske eksempel er HTTP server kode i Squid og Apache, der spilder tid med at lave tekstbehandling af HTTP headers der ikke efterfølgende vil blive brugt til noget.

Den nemmeste måde at få kode til at spare strøm ved ikke at spilde tiden, er at give udviklerne maskiner der kun kører 1/10 så hurtigt som kundernes hardware.

Poul-Henning

  • 0
  • 0

PH:

Applikationen bliver ikke langsommer af kode der ikke exekveres.

Enig. Men, en snæver analyse.

Sammenhængene er: Applikationer der er unødvendigt fede, fylder, og jo flere af sådanne som en bruger behøver at anvende på samme tid (i forhold til mængden af fysisk hukommelse diverse steder i et system), jo mere skal et operativsystem indlæse og udsmide på skift, som giver en langsommere brugerflade, og måske skal dele af hardwaren vækkes fra en dvaletilstand på grund af dette, som måske vil medføre et større strømforbrug af den årsag. Eller: Hvis en bruger vælger at fodre de fede applikationer med ekstra fysisk hukommelse, da bruges der mere strøm, som (måske) vil betyde en større fysisk vare, og (måske) mere larm fra varen (fra en eventuel blæser), eller (måske) større vægt (fra eventuelle passive køleflader). En unødvendig fed applikation, som allerede er indlæst i den fysiske hukommelse, er derimod ikke langsommere til sit job, end en korrekt mager applikation, alt andet lige. Det fede problem er sjældent et problem når man fokuserer på een applikation, det er når man lægger mange af disse sammen (ofte fra vidt forskellige producenter), at fede exe-filer afsløres at være noget juks. Producenter af ekstra moduler til en hardware (fx lydkort, grafikkort, det vil sige udstyr der non-stop bliver anvendt i et system) er nu og da fuldstændig uansvarlige i deres sløseri med unødvendigt alt for fede applikationer. PH vil muligvis svare, at streaming (den slags) fra servere til slanke klienter har løst alle sådanne problemer, men der er trods alt stadig mange personlige computere i anvendelse på en decentraliseret måde, og mobile telefoner af cirka tilsvarende art er også fyldt med applikationer. Moderne biler, blot et eksempel, risikerer at gentage dette mønster i fremtiden. Skal brugerne da blot købe en bil med en kraftigere computer? Ja, vil svaret være i USA, men ikke i Danmark, hvor skattetrykket på al hardware gør fed software til en dyr investering for køberne.

Jens:

Endeligt, medfører pointere en langt større kode, og dermed større forbrug. Hvis f.eks. pointeren er på 32 bit, så kræves en simpel move at 64 bits læses, eller 8 bytes. Dertil kommer indstruktionsord og opslag i ram lageret, fra de to addresser, og overførsel af værdien.

At pointere er uoptimale at anvende til simple stumper af kodning i et program, er korrekt, og en årsag til at mange programmører aldrig gider at udvikle sig så langt som til at overveje at anvende pointere til de seriøse opgaver: Lige så snart som at et program skal gennemsøge et mylder af data og sortere og ændre på dem og deres indbyrdes sammenhænge, sparer man på enorme mængder af kopieringer på data i den fysiske hukommelse, ved at anvende pointere. Lænkede lister, lænkede cirkler, træer, køer, stakke, objekter, records, tabeller, alt sådant kan man kyle vidt omkring som en jonglør i et program ved hjælp af pointere, med rasende hurtig performance i forhold til naive anvendelser af fx strenge der kopierer fra hinanden, og nu og da kan man fuldstændig undvære en vedvarende kobling til en disk-baseret relationsdatabase, det vil sige indlæse en (forholdsvis) enorm hel database i hukommelse og håndtere alt dér på een gang (fordi man med pointere kan spare voldsomt på hvor meget relationsdataene fylder tilsammen), og imens kan hjælpesystemer aflæse status og nedskrive til disk, således at alt stadig kan genskabes i tilfælde af nedbrud. Konceptuelt, at anvende pointere, er en anderledes måde at tænke på, filosofien er at ville pege til peg der peger til peg der peger til data (...), og filosofien er også, at man så vidt muligt undlader at flytte på data hvis det er nok at ombytte nogle pointere, fordi pointere intet som helst fylder i forhold til typiske data. I praksis kan det ligne at man sammenbinder et stort antal af pindsvin via deres pikke og hvoraf mange (så mange som muligt) af pindsvinene og pikkene reelt er kun spøgelser (referencer til andre), og Jens har ret i, at sådan kode kan være vanskelig at analysere, fordi abstraktionsgraden er stor. Deraf behov for meget skrap arkitektur i sådan software, behov for konsekvens, behov for at arkitekturen er beskrevet, ofte tegnet, ikke kun kodet. Den færdige vare vil tilbagebetale rigeligt for dette, være lynhurtig og skalere virkelig godt, med et brutalt loft i form af den mængde af RAM som et system kan indeholde, et loft der i praksis er temmelig højt, fordi pointerbaseret programkode er nøjsomme med deres forbrug af hukommelse.

Jens:

Mest optimalt, er at læse data direkte fra pipelinen.

Dette er på konceptuel måde en slags pointer-filosofi, i den forstand at man undlader at kopiere data, refererer i stedet til en oprindelig kilde. Desuden er det ofte optimalt at modtage og anvende data ved at aflæse fra visse faste positioner i en binær række af udokumenterede data, hvis man kan stole på at skaberen af rækken altid sørger for at positionere "lovlige" data korrekt i rækken, en filosofi der også er en slags pointer-filosofi. Konkret programmeringsmæssig anvendelse af pointere, som variabler, er kun en fordel at anvende, når hver stump af data skal anvendes mange forskellige steder i en applikation på een gang, og når disse data samtidig skal flyttes meget omkring imellem hinanden. Fx geometriske data bliver ofte håndteret med pointere, fordi der er mange af disse data ad gangen og fordi diverse funktioner har behov for at gennemtrevle disse data i stor fart i vidt forskellige sorteringer. Jeg vil tro, at alle teknisk set gode 3D-computerspil er baseret på eet stort virvar af indbyrdes forbundne pointere. Jeg vil også gætte på, at alle servere, der smider store mængder af relationsdata ud til brugere via Internet, er baseret på databaser der er kodet ved hjælp af lutter pointere. Desuden er applikationer der inderholder et meget stort antal af brugerflader (vinduer) der er fyldte med felter, ofte også programmeret med pointere, fordi man således kan spare på en enorm bunke af gentagelser af kode.

  • 0
  • 0

Den nemmeste måde at få kode til at spare strøm ved ikke at spilde tiden, er at give udviklerne maskiner der kun kører 1/10 så hurtigt som kundernes hardware.

Poul-Henning

Samt en anelse mindre ram. Piccolo, evt. partner skulle være passende ;-)

M

  • 0
  • 0

PH:
[quote]Applikationen bliver ikke langsommer af kode der ikke exekveres.

Enig. Men, en snæver analyse.

Sammenhængene er: [...]
[/quote]

Nej Carsten,

Sammenhængen er præcis hvad jeg startede med at skrive: Du har ikke forstået en disse om hvad Virtuel Memory er, hvad det bruges til eller hvordan det skal bruges.

Men du er i godt selskab, jeg har kun mødt ganske få personer der havde en korrekt intuitiv forståelse for dette.

Meget af hvad du skriver var rigtigt på en Partner eller under MSDOS 3.11.

Men det er altså 25 år siden.

Poul-Henning

  • 0
  • 0

sparer man på enorme mængder af kopieringer på data i den fysiske hukommelse, ved at anvende pointere. Lænkede lister, lænkede cirkler, træer, køer, stakke, objekter, records, tabeller, alt sådant kan man kyle vidt omkring

Delvis korrekt - men beskriver du det med pointere, begynder du at fortælle compileren "hvordan" den skal løse det. Bedre er det, at lade den lave pointerne selv - og fortælle at data skal kopieres. Det som er "pointen", er at compileren skal vide hvad du gør. Hvis du ser og taster opskrifter ind, og fortæller i detaljer hvordan du vil løse en opgave - så går selve idéen tabt. Og compileren oversætter ofte ineffektiv. Det bliver op til programmøren at "justere" softwaren, så den kører effektiv, og ikke et resultat af algorithmer som er bag compileren.

Det kan naturligvis også gøres - som PH siger, så giv programmøren en ZX81... Mange microcontrolere, er i denne størrelsesorden, med hastghed på ned til 1 MIPS. Det betyder, at de naturligvis har et meget lavt strømforbrug, og ikke kan kodes til et stort...

Jeg tror dog, at fremtiden ligger i, at compileren har føling med softwaren, og derfor kan udføre de nødvendige optimeringer. Som eksempel, kan det være en compilers opgave, at sørge for der ingen kode køres hvis et ur er scrollet uden for skærmen. Når uret er inden for skærmen, vil compileren gøre, at softwaren aktiveres hvert sekund, så viseren kan flyttes. Det kan være relevant, at compileren kan analysere at "resultatet" ikke bruges, og den derfor kan forkorte koden bort, og endog fjerne aktiveringen af her tidsinterruptet, så den først aktiveres, når uret flyttes indenfor det synlige (af et andet interrupt).

Skal du selv optimere softwaren så kan det tage tid. Fremtiden er, at automatikken gør det. Og, at lave sprog, så det er nemt at kode - uden du skal tænke "hvor besværligt - gidder jeg det".

I langt de fleste tilfælde, skyldes manglende optimeringer, at programmørerne synes det er besværligt. Sprogets opgave, er at gøre det nemt. Og det skal være analyserbar, så så meget som muligt, kan gøres "intelligent", og overtage det besværlige arbejde for programmøren.

Der er mange effektive pointerstrukturer, og det er ikke sådan jeg siger, at pointere ikke må bruges. Relative pointere, kan være enormt kompakte, hvis hardwaren forstår dem, og kræve færre bits der ændres. Det jeg mener, er kun at pointerne gerne skal skjules fra programmøren, så at det er essensen der fortælles compileren, og at den så selv lægger pointere ind - hvis det er den fornuftige løsning. Derved, kan bedre løsninger opnås, ved at forske i compilere, og lave bedre løsninger. Koden, som leveres til compileren, skal derfor helst være analyserbar - og her er pointere noget skidt.

Det er korrekt, at mobiltelefoner efterhånden har udviklet sig til regulære computere, med mulighed for at uploade 3. parts kode - og dermed synes jeg egentligt, at de er på vej bort fra at være embedded kode. De er mere en "rigtig" computer.

Det er korrekt, at advancerede operativsystemer, der indeholder multitasking og virtual memory, ofte bruger CPU resourcer på at optimere for hurtigst mulig svartid. I nogle sammenhænge sker det på bekostning af strømforbrug. Ved at low-power system, er derfor relevant, at bruge færre resourcer på optimering I nogle tilfælde, kan det dog være relevant, fordi at det netop medfører hurtigere svartid. Og dermed, er også relevant at optimere anvendelsen af virtual memory, som du nævner. Dette er dog mest en operativsystem ting - hvis vi ser på hvad programmørene skal, så går det mere i retning af, at slukke for de dele, der ikke bruges, og tændes når de skal bruges, samt at sikre softwaren er eventdrevet, og ikke indeholder delayløkker, eller poll-lykker.

  • 0
  • 0

Meget software indeholder også kopiering - og her er korrekt, som Carsten siger, at dette bør undgås - f.eks. ved at bruge pointere. I princippet, så er dog bedst, hvis at compileren gør "trikket". I nogle tilfælde, kan hardwaren måske også indeholde dele der gør, at "kopiering" ikke er nødvendigt, f.eks. hvis den indeholder en oversættelsestabel. Dertil er naturligvis vigtigt med effektive algorithmer. Og endeligt, at selve designet er lavet med henblik på at spare strøm. En kommunikationsprotokol, og hardware, der lavet til at fråse, kan det være svært for software at gøre noget ved.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten