Derfor bliver din pc kvalt i software

Software er blevet så tungt, målt på antal bits, at hardwareudviklingen virker stagnerende. Resultatet er software, som ingen forstår, mener eksperter.

Det er ikke kun i den vestlige verden, at fedme er blevet en slags epidemi. Også i den digitale verden lider software under et stødt stigende antal kodelinjer. Og det er problematisk, fordi resultatet er, at ingen har et tilbundsgående overblik over, hvordan it-systemer faktisk virker, mener eksperter.

Umiddelbart kunne man måske sige: ?Ja, en lydkortsdriver fylder 40 megabyte ? og hva' så?? Men mens softwaren tager på, øges den samlede softwarekompleksitet og dermed også uoverskueligheden.

»Som samfundsborger, mener jeg, det er problematisk, fordi øget kompleksitet også betyder mere ustabilitet og flere sikkerhedsrisici, som hackere kan udnytte. Og sådan, som det er nu, tror jeg ikke, der er nogen ? heller ikke hos softwareudviklerne ? der har det fulde overblik over, hvordan programmerne faktisk fungerer,« siger prorektor og professor ved IT-Universitetet i København Jørgen Staunstrup.

Også set ud fra en fagmands synspunkt finder han udviklingen problematisk, fordi det evigt voksende antal kodelinjer kunne begrænses af mere elegante programmeringsløsninger, mener Jørgen Staunstrup. Et af problemerne i den sammenhæng er dog, at moderne programmører bliver presset fra blandt andet marketingsafdelinger, så de dermed mister fokus på effektive programmeringsløsninger, mener han.

Der mangler et fundamentalt gennembrud inden for software, hvis kurven med stadig tungere programmer skal knækkes, påpeger Jørgen Staunstrup.

Han fortæller, at det engang var sådan, at når man skulle bygge en havnekaj, så var der ingen, der helt vidste, hvor meget cement der skulle bruges for, at kajen ville holde. Men så opdagede et dansk ingeniørfirma nogle nye metoder, som betød, at kajerne kunne bygges med væsentligt mindre cement, uden det gik udover holdbarheden.

»Vi mangler et gennembrud inden for softwareudvikling, så vi får en dybere forståelse for, hvad der skal til, så vi ikke hælder unødvendigt cement i vores programmer,« siger Jørgen Staunstrup.

Mens vi venter på gennembruddet, vokser softwaren altså fortsat. Og Jørgen Staunstrup mener i den sammenhæng, der er hold i den såkaldte The Great Moore's Law Compensator, der i al kortfattethed går ud på, at fremskridt inden for hardwarehastighed bliver ædt op af softwarens vokseværk.

Bagudkompatibilitet

Men hvorfor vokser softwaren egentlig? Der er selvfølgeligt øget funktionalitet og pænere grafik, der forklarer en del af fænomenet. Men Jørgen Staunstrup mener alligevel ikke, det kan forklare, hvorfor et styresystem i dag fylder en DVD, mens det for ti år siden kunne ligge på en CD. Han peger på, der mangler et egentligt incitament til at gøre softwaren mindre, fordi hardwaren alligevel følger med.

Jørgen Staunstrups kollega ved IT-Universitetet professor Søren Lauesen mener, den digitale vægtforøgelse delvist kan forklares med, at programmører bygger videre på eksisterende software i forsøget på at honorere ønsket om bagudkompatibilitet

»Desuden bygger man nyt software ved at kombinere eksisterende store stykker software. Så bliver det hele mange gange større. Det er fordi, man ikke vil genopfinde hjulet,« siger Søren Lauesen, som erkender, at det er urealistisk at genopfinde hjulet inden for programmering, sådan som it-verdenen ser ud i dag.

»Desværre får man nogle interaktionsproblemer, med det der findes i forvejen, fordi man ikke forstår, hvad det er, man bygger ovenpå,« siger han.

Som konkret eksempel på noget af den mystik, der omgærer moderne programmer og computere, nævner Søren Lauesen det nye grafikkort, han har fået i sin computer. Efter kortet blev installeret har hans Windows installation mistet evnen til at gå i dvaletilstand.

»Det er et godt eksempel på, hvordan ting på en helt uforudsigelig måde modvirker hinanden,« siger han.

Men en ting er uforudsigelig opførsel i forhold til dvale og grafikkort. Noget helt andet er, når den it, der styrer moderne samfund, også begynder at opføre sig uforudsigeligt.

Jørgen Staunstrup bryder sig ikke om udtrykket 'lig på bordet', alligevel frygter han, at der skal en alvorlig it-relateret katastrofe til, før samfundet og ikke mindst softwareproducenterne får et incitament til at lave softwaren slankere.

»Selvom jeg ikke ønsker det, så tror jeg, at nogle virkeligt alvorlige softwarenedbrud, som fik os alle sammen til at erkende, hvor alvorligt det er, ville sætte en udvikling i gang,« siger han.

Og i den sammenhæng er det netop passerede nedbrud hos IBM, som berørte flere danske virksomheder, ikke alvorligt nok, mener Jørgen Staunstrup. Han henviser til, at nedbruddet ikke berørte nok privatpersoner.

Omvendt medicin

Paradoksalt nok forholder det sig omvendt med softwareudviklingen set i forhold til eksempelvis den medicinske udvikling, påpeger Søren Lauesen. Mens det, der foregik inden i det menneskelige legeme for flere hundrede år siden, var omgæret af mystik, så har vi i dag en meget bedre forståelse for, hvordan lever, nyrer og lunger fungerer. Men med software er det lige omvendt, fortæller Søren Lauesen:

»I gamle dage spurgte man en klog kone til råds, når man fejlede et eller andet. I dag er det kloge it-folk, man spørger, og de har kun kvaksalverråd at give. På computerområdet er det ligesom gået baglæns,« siger Søren Lauesen, som er meget lidt begejstret for udviklingen inden for software:

»Faktisk har jeg det ret dårligt med det. Specielt det der med, at man ikke længere forstår, hvad der foregår. Du kan søge rundt på internettet, og der er sjældent nogen, der kan komme med en forklaring,« siger Søren Lauesen, som også mener, udviklingen forholder sig, som The Great Moores Law Compensator foreskriver, og han beklager den udvikling.

Infoworld.com bragte fornyeligt en artikel under overskriften 'Fat, Fatter, Fattest", som blandt andet beskrev, hvordan Microsofts nyeste Office-pakke under Windows Vista sluger mere end 12 gange så meget ram og næsten tre gange så mange processorressourcer som Office-pakkens syv år gamle forgænger.

Hvad mener du?
Er det overhovedet realistisk at forestille sig, at moderne software kan sendes på slankekur, uden det går udover funktionalitet, brugeroplevelse og kompatibilitet eller er udviklingen i størrelsen af software bare en naturlig del af nye versioner?

Deltag i debatten herunder og stem i Version2s barometer til venstre på denne side.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jacob Christian Munch-Andersen

Når du sætter computeren i stand by så skal den slukke for skærmkortet og kunne tænde det igen med informationerne bibeholdt, derfor bliver Windows nødt til at kommunikere på en lidt mere kompleks måde med skærmkortet, hvilket kræver ordentlige og korrekte drivere. Hvis du ikke har installeret den rigtige driver så kan computeren ikke succesfuldt gå i stand by.

  • 0
  • 5
#4 Christian Nobel

Jeg ser et stort problem i at mange laver programmer med et ekstremt overhead, f.eks. ved at lave .NET (eller Mono) programmer, hvor det er nødvendigt at slæbe rundt med hele frameworket bare for at lave en "Hello World"

Og så er der alle de programmer der fordrer et hav af afhængigheder (.dll/.so) som så måske også bruges af andre programmer, hvor der så kommer ged i den når en af afhængighedsfilerne af vanvare bliver udskiftet osv. osv.

Måske er vejen slet ikke at opfinde nye metoder, men mere gå tilbage til gamle dyder, så som kompilerede monolitiske programmer (og ikke noget installationsfis!) - det sværger jeg i hvert fald til.

/Christian

  • 1
  • 0
#6 Chris Kjær

Enig!

Medvirkende årsag til bloat er også, at udviklerne tit har rimeligt nye og kraftige pc'er - så de opdager ikke selv, hvor sløve deres ting fungerer på 'hvermands'-maskiner.

Tænk hvis Vista var blevet udviklet på pc'er som de, der fik 'Vista Capable' klistermærket...

(Indvending 1: 'Compileren æder en masse ressourcer' - men det behøver den ikke. Tænk tilbage til f.eks. Turbo Pascal, der fyldte 30-40 kB og kørte lynhurtigt på en 8 MHz 8088...)

  • 0
  • 0
#7 Anders Olsen

Når vi snakker drivere, så behøver drivere ikke at fylde alverden. Jeg vurderer at samtlige drivere til samtlige chipsets og devices på min indeværende desktopmaskine (ca 80) fylder ca 5 mb. Men det er oss drivere og en enkelt nvidia driver.

Specielt med lydkort- og printerdrivere kan man med fordel vælge generiske drivere, hvis man ikke har brug for meget speciel funktionalitet. Så slipper man osse for at Creative, Logitech, Hp eller hvem det nu er, sluger 20-30 Mb ram på permanent at ligge og checke om de er opdaterede og den slags.

  • 0
  • 0
#8 Deleted User

En af mine grunde til at bruge andre OS end Windows er blandt andet muligheden for at lære mere om hvad der foregår under overfladen. Nej, kode er ikke selvdokumenterende, men der er heldigvis mange i OSS verdenen der forsøger at dokumentere hvad der foregår.

Det kan da blive meget bedre, bevares, men der er godt nok stor forskel på "klik på den her for at få DHCP" magic-wand , og så "man 8 dhcp"

  • 1
  • 1
#9 Jørgen Henningsen

Man kan ikke jage den gode brugeroplevelse uden at bruge resourcer det er klart. Jeg tror det simpelthen bare er svært for programmøren at bevare overblikket over hvor mange resourcer som man beslaglægger. Mange steder får man at vide at det skal man ikke tænke på fordi PC'erne bliver hurtigere og hurtigere.

Det som gør meget af brugeroplevelsen er jo brugerfladens responstid. Der skal helst ske noget når man klikker på en knap eller et menupunkt. Det er dødens pølse hvis man skal vente flere sekunder på at der kommer en menu.

Pop og pynt såsom animerede ikoner og flyvende dokumenter burde kunne bortkonfigureres. Det kan genere mig meget at windows bruger tid på at animere flyvende dokumenter istedet for bare at skrubbe igen med at få kopieret min fil. Ubuntu har jo f.eks. muligheden for at justere niveauet af visuelle effekter.

  • 0
  • 0
#10 Kjeld Flarup Christensen

Firefox reducerer faktisk http://www.version2.dk/artikel/6645

Og jeg kan også stadigt huske gode gamle GEM, der kunne køre på computere det havde færre ressourcer end en moderat mobiltelefon.

Men når det er sagt, så tror jeg at der ikke er ret meget vej udenom, men jeg er dog ikke så skeptisk som Jørgen Staunstrup.

Kodebasen vil vokse af flere grunde. Den vigtigste er faktisk stabilitet. Når udviklere skal lave nye smarte applikationer, så trækker de komponenter ind, og det koster. Men komponenter er tilgengæld også bedre testede.

Så er det selvfølgelig sådan at ikke alle bruger de samme komponenter, så det koster også lidt ekstra.

Der hvor komponenterne så hidtil har fejlet er når to programmer har brugt forskellige versioner af de samme komponenter. Især Windows har været et helvede hvad det angår, men på Linux/Unix har det altid været overkommeligt at installere flere versioner, og det koster så igen.

Så alt i alt ser jeg det ikke som en stor risk.

Og grafikkort eksemplet er faktisk lidt på tværs af problemet med ressourceforbruget. Understøttelsen af al den nye hardware er et reelt problem i forhold til både Windows og Linux. Linux folket er måske lidt heldige fordi producenterne ikke selv gider lave deres Linux drivere.

Men som "kerne tilpasser" så kan jeg godt se at selv Linux kernen bliver mere og mere kompleks at danse med. Men kernens ressourcekrav følger altså ikke Moores lov, langt fra!

  • 0
  • 0
#11 Peter Andersen

Mit første tekstbehandlingssystem kørte på en 4MHz Z80 baseret hjemmePC under CPM, 128 KILObytes ram og hed vist wordstar. Man skulle selv definere bredden på bogstaverne på udskriften så man wordstart kunne lave lige højremargen.

Ok - dertil ønsker jeg mig ikke tilbage. Men i knap så gamle dage kørte jeg Word 2.0 på en Windows 3.11 ramt 386, 40 MHz, 4 MB ram - jeg havde truetype fonte, spalter, tabeller, mulighed for at indsætte grafik, stavekontrol indholdsfortegnelse osv.

Bortset fra lange filnavne var mine tekstbehandlingsbehov dækket. Word kunne vist ligge på nogle få DISKETTER, dvs under 10 mb.

Kan I huske antivirusprodukterne der skulle kunne ligge TSR i DOS's beskedne 640KB adresserum - de måtte ikke fylde meget, 20-30KB kunne det være. Min Panda i dag er en 80MB download, og det er den SKRABEDE udgave!

Man kan kode til mobiltelefoner, spillekonsoller, og andet udstyr med embedded software og bekrænsede hardware resourser, det er vel et spørgsmål om valg.

Jeg tror udviklerne klatterne med PC'ens resourcer fordi de kan - der er sku ingen der klapper dig på ryggen fordi du laver en 30kb lyddriver i stedet for en 30mb.

  • 1
  • 0
#12 Martin Kock

Al software udvikles jo med strikse deadlines. Programmørens prioritet er altid at få softwaren til at virke. Når det virker kan man begynde at optimere.

Men hvis ingen beklager sig over at det er langsomt, og chefen allerede begynder at tænke over det næste store IT-projekt, hvem bekymrer sig så om optimering?

Tid brugt på at optimere Office-pakkens ressourceforbrug kunne være brugt meget bedre på at gøre kunderne tilfredse ved at implementere smarte ekstra-features.

  • 0
  • 0
#13 Jens Madsen

der mangler et egentligt incitament til at gøre softwaren mindre, fordi hardwaren alligevel følger med.

Softwarens størrelse, medfører ikke nødvendigvis at koden bliver tungere - antallet af instruktioner der udføres, er det som gør koden tung. Ikke kun tager det tid - men det koster også strøm. Og netop batteriforbruget burde være motivationen for at lave effektivt og hurtig kode. Hver instruktion har et energiforbrug i joule, og det kan kun svært blive mindre. Udføres en kode dobbelt så hurtigt, så forbruges også den halve energi - og batteriet holder det dobbelte.

Der findes mange måder at gøre kode effektivt. Som eksempel, kan man sætte krav til programmørerne om, at programmet skal have bestemt svartid. Indenfor HW har ethvert hardwareprogrammeringssprog mulighed for at lave statiske analyser på svartid. Samme kan gøres indenfor SW. Dog, så vil det kræve, at enhver loop maksimale antal gennemløb kan gennemskues af automatik - hvilket i praksis betyder, at vi manuelt må sætte en maksimal grænse på antallet af loop. Og dette kan reelt tvinge programmørerne til, at må anvende mere effektive algoritmer, der svarer i O(log(n)) tid, for at kunne udføre en opgave.

Det bliver utroligt svært, at få programmørerne til dette, uanset algoritmerne kendes i datalogien. I dag er metoden blandt de fleste programmører stadigt, at de søger telefonbogen igennem, for at finde et null symbol, for hver eneste gang de har behov for at kende datamængdens størrelse - i stedet for, at gemme størrelsen i første position, så den huskes. Og at telefonbogens data står i numerisk rækkefølge anvender de færreste, da det ikke er så sikkert (data kan jo være anbragt forkert). Og dem der gør, ender med at få høvl fordi deres software er dårligere og mindre sikker, og ikke kompatibelt.

  • 0
  • 0
#14 Erik Hougaard

Ingen tvivl om at der hele tiden kommer mere kode til, men jeg kan se på vores produkter at det som virkeligt øger størrelsen på installationsmediet er ressourcer, dvs. billeder, lyd, video etc.. Nu skal alt fra ikoner til baggrundsbilleder jo se flot ud på en "retina" skærm - Så det fleste bitmaps er lige blevet 4-doblet i størrelse..

  • 0
  • 0
#15 Jørgen Henningsen

Måske kunne man begynde at tænke lidt mere i behovsanalyse. Kan man f.eks. sætte tal på hvor hurtigt en grafisk brugerflade reagere på museklik/taste tryk? Og hvad er egentligt behovet hvis man vil give en god brugeroplevelse? Hvis man kan sætte tal på og dermed kravspecificere en brugeroplevelse, så har man også et mål med den software man vil udvikle og kan derfor vælge de rette teknologier.

  • 0
  • 0
#16 Jens Madsen

Det er korrekt, at en af parametrene til strømforbruget er, hvor mange instruktioner der udføres. Men kodens størrelse betyder bestemt også noget. Forbruget er langt større for en byte, som skal hentes ind fra lager - eller måske harddisk - og risikoen for det, er langt større, når koden fylder meget. Er koden stor, så er der oftest langt flere cache misses, og koden er splittet over et større område. Det som betyder noget, er at tunge algoritmer er kompakte, og at de har fornuftig cache styring. Selve softwarens størrelse, betyder mindre. Men, det er ikke ualmindeligt, at der er sammenhæng mellem stor kode og ineffektivitet. Stor kode, er ofte et udtryk for, at den ikke er gennemtænkt, eller genereret automatisk, af ineffektiv og dårlig software. Det betyder, at de kompakte og effektive algoritmer, for længst er kasseret og smidt bort og fjernet. For hver gang vi ser nye udgaver af software, så vokser koden, og de effektive algoritmer fjernes.

  • 0
  • 0
Log ind eller Opret konto for at kommentere