Selvlærende IBM-compiler giver bedre ydelse

IBM og EU står bag ny, selvlærende compiler, som kan optimere applikationer på egen hånd. Det kan f.eks. gøre udvikling af software til mobiltelefoner ti gange hurtigere.

IBM Research og EU sender en ny, open source compiler på gaden i dag. Den har navnet Milepost GCC, og er ifølge IBM verdens første maskinindlærings-compiler.

Den snørklede betegnelse dækker over, at compileren bruger kunstig intelligens til at analysere, hvordan et program kan optimeres, skriver IBM i en pressemeddelelse.

Det er sket ved at åbne compiler-miljøet, så det kan tilgå kunstig intelligens og maskinindlæring og på denne måde bestemme, hvilke optimeringer der skal anvendes hvornår.

Foreløbige eksperimenter, foretaget på en IBM System p-maskine (tidligere kendt som RS/6000) opnåede gennemsnitlige forbedringer i ydelse på 18 procent i en benchmarktest.

Den nye compiler er et resultat af et samarbejde mellem IBM og partnere i det EU-sponsorerede konsortium Milepost. IBM forventer, at compileren drastisk kan nedsætte den tid, det tager at få et stykke software på markedet, da applikationer hurtigere kan finjusteres til bestemte arkitekturer.

Eksempelvis kan det tage måneder for producenter af mobiltelefoner at få softwaren til at yde tilfredsstillende. Ifølge IBM kan denne tilpasning reduceres i tid med en faktor ti.

»Vores teknologi lærer automatisk, hvordan man skal få den bedste ydelse fra hardwaren - uanset om det er mobiltelefoner, skrivebords-pc'er eller hele systemer. Softwaren vil køre hurtigere og bruge mindre energi,« siger Bilha Mendelson, som er chef for kodeoptimering hos IBM's forskningslaboratorium i Israel, ifølge pressemeddelelsen.

Konsortiet bag Milepost-teknologien har sat et website i verden, hvor udviklere kan uploade kildekode og få input til, hvordan koden kan finjusteres til at køre hurtigere.

Compileren er tilgængelig fra konsortiets website, som kan finde via det eksterne link herunder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Carsten Pedersen

Det er vist overskrift-redacteuren som har haft lidt travlt... Det lyder ikke usandsynligt at en intelligent compiler kan reducere programmør-tiden tilbragt på optimering heftigt, især i miljøer hvor hardwaren hele tiden ændrer sig og programmørerne kan have svært ved at følge med.

Gevinsten i køretid er da også "kun" 18 procent siger artiklen. Det er så blevet til "10x" i resumeet.

  • 0
  • 0
Johan Holst Nielsen

Carsten, du misforstår artiklen i så fald.

De der står, er at performanceydelsen - pga. optimeringer i koden - vil blive 18% bedre.

Mens tiden der bruges på optimering af en ikke-given applikation kan reduceres med 90%.

Om disse tal er NPOOA vil jeg ikke forholde mig til - men der er da en vis chance for det :)

  • 0
  • 0
Torben Mogensen Blogger

Man får i reglen mere ud af at bruge bedre algoritmer end ved at lave lavniveauoptimeringer i stil med det, en oversætter kan lave. Men 18% er da værd at tage med.

Men at man skulle bruge 10x mere tid på at opnå dette ved håndarbejde kan jeg kun forestille mig i sjældne tilfælde, og kun hvis programmørerne ikke fra starten af koder effektivt. Men sådanne kodere findes der desværre mange af. Jeg har været censor på et speciale om Go-spil, hvor metoden til at se om et tomt felt er omgivet af brikker af modstanderens farve eller af kanten var implementeret på følgende vis:

  1. Opret en tabel, der har to flere rækker og søjler end brættet og indsæt modstanders farve på alle felter.

  2. Kopier brættet over i den nye tabel med offset (+1,+1).

  3. Undersøg om feltets fire naboer (med offset (+1,+1)) i det nye bræt er af modstanderens farve.

Her hjælper en optimerende oversætter ikke meget, men en bare nogenlunde kompetent programmør kan på få minutter omkode denne metode til at køre mindst 100x hurtigere.

  • 0
  • 0
Tania Andersen

De ti x henviser til flg. afsnit:

"Eksempelvis kan det tage måneder for producenter af mobiltelefoner at få softwaren til at yde tilfredsstillende. Ifølge IBM kan denne tilpasning reduceres i tid med en faktor ti."

  • 0
  • 0
Jens Madsen

Skal en optimering være noget værd, er det ikke noget med 18% - det er store O funktionen, som skal reduceres.

Dette, kan man endnu ikke opnå maskinelt. I nogle ganske få tilfælde, kan det opnås til dels med hardware, f.eks. deciderede kopimaskiner, som kan gøre kopiordren hurtigere. Men, normalt må man ikke forvente at maskinel compilering, kan gøre noget ved hastigheden.

Det som hjælper, er at skrue bissen på overfor koderne. De skal have regler for, hvor store kompleksitet store O funktionen må have for deres software. Og de skal tvinges til at bruge rutiner, der har optimal store O funktion, fremfor at bruge deres egenskrevne rutiner. De skal tænke i retning af, hvordan stykker vi koden sammen, med kendte rutiner, der har god store O funktion, og opnår en optimal store O funktion udfra det.

Mange gange, genopfinder programmørerne de dybe tallerkener. De sidder og programmere heaps, rød-sort træer, databaser mv. uden reelt at vide det - fordi at opgaven måske er en anden. Det kan være f.eks. at angive nogle grafer på en skærm, der scrolles frem og tilbage. Her, indses måske ikke, at det kan gøres med f.eks. rød-sort træer, eller heaps. Og det betyder, at der fås for høj store O funktion i nogle tilfælde. Måske, er det en "linær" funktion, at tilføje en ny event, på en dobbelt kædet liste, og det tager jo så lang tid. Der opdages ikke, at det tager tid, før brugeren anvender softwaren. Hvis man som standard, havde anvendt standard rutiner, f.eks. rød-sort træer, eller heaps, så var det gået hurtigt, i alle tilfælde. Nogle typer heaps og rød-sort træer, kan også være kombineret med dobbeltkædede lister, hvis det ofte skal skrives ud i bestemte rækkerfølger. Det vigtige er, at gøre det til en selvfølge, at anvende optimale store O funktioner - for så kan metoden bruges i mange andre sammenhænge. Et andet eksempel er sortering af data på en skærm - det tager også ofte tid. Igen, behøver det ikke at tage tid, hvis data fra start anbringes i sorteret rækkefølge, f.eks. ved anvendelse af balancerede søgetræer.

Hvis programmørerne får dikteret store O funktionen, f.eks. af en datalog der er rutineret i at gennemskue hvor stor store O funktioner behøver at være for en opgave (standard svaret er O(log(n))), så vil meget software gå hurtigere.

Det er næsten umuligt at lave noget langsomt, hvis man holder sig fra nul-terminerede datatyper og strenge, der søges igennem linært, og andet der skal søges igennem linært, eller værre.

  • 0
  • 0
NA NA

kun hvis programmørerne ikke fra starten af koder effektivt. Men sådanne kodere findes der desværre mange af

Sådanne kodere kan man kun få for mange af. Optimeret kode er typisk af ringere kvalitet på alle parametre undtagen afviklingshastighed, f.eks. i forhold til læsbarhed.

Det er ret tit at måske 90 % af ens kode står for så lille en del af afviklingstiden at det er formålsløst at optimere det. Optimering er ikke noget der er hensigtsmæssigt at foretage mens man implementere et program. Optimering er noget man foretager efter man konstateret et konkret behov for at øge hastigheden på en del af ens kode.

  • 0
  • 0
NA NA

Mange gange, genopfinder programmørerne de dybe tallerkener. De sidder og programmere heaps, rød-sort træer, databaser mv. uden reelt at vide det - fordi at opgaven måske er en anden

I de 10 år jeg har arbejdet som software udvikler for en række forskellige virksomheder og projekter har jeg ikke en eneste gang stødt på nogen der har anvendt andet end arrays og hashtabeller - som iøvrigt også er et fint valg 90 % af tiden.

  • 0
  • 0
Erik Cederstrand

Optimering er ikke noget der er hensigtsmæssigt at foretage mens man implementere et program. Optimering er noget man foretager efter man konstateret et konkret behov for at øge hastigheden på en del af ens kode.

Og når det så ikke kan lade sig gøre, fordi man ikke har tænkt sig om i designfasen, så står man med en dårlig sag hos chefen.

Det er en noget bastant udmelding, synes jeg. Selvfølgelig skal man ikke optimere for optimeringens skyld, men man skal bestemt have krav til svartider, antal brugere, datamængder, hardware osv ved hånden helt fra starten.

  • 0
  • 0
Brian Vinter

Nej!

Hvis du ændrer kompleksiteten af løsningen så laver du en ny algoritme, det er ikke en optimering men en alternativ løsning (det vil i alle fald være notationen blandt dem der udvikler os, compiler og de fleste apps!).

Jeg kan ikke tælle hvor mange gange jeg har fået serveret ideen om at vi skal bare bruge pengene på nye algoritmer og så ellers vente på at HW udvikler sig/tilpasser sig, specielt i Danmark hvor optimeringer med konstante faktorer (som forsvinder når man angiver kompleksitet) ofte afskrives som uinteressante. Men hvis man har en maskine til 100Mkr som man med en kode-optimering får til at køre 2x hurtigere så har man altså tjent/sparet en masse penge!

Bemærk også formuleringen "applikationer hurtigere kan finjusteres til bestemte arkitekturer". De der har prøvet at kode til fx CELL vil påskynde det - efter 3 år er compilerne stadigt temmeligt ringe til at generere SPU kode og de overvejer slet ikke memory-transfers.

Om "AI" så er måden at gøre det på er jeg noget mere spændt på - men hvis compileren leverer varen (og koden stadigt er korrekt :)) så er jeg helt klart kunde!

  • 0
  • 0
Martin Zacho

Kompleksitetsanalyse er ikke det eneste saliggørende i denne verden - den er rigtig god, når man skal se på løsninger, der skal kunne skaleres til store problemer, men til mange dagligdags problemer er en hurtig liniær søgning eller lign. fuldt tilstrækkeligt, da man kender problemets maksimale størrelse og ikke ønsker at bruge tid, kræfter og datalager til mere generelle og skalerbare løsninger.
I ingerniørens verden kan der, som Brian også skriver, være en stor betydning i at O(1e-3 * n^2 + n + 1e3) = O(n^2).
Ofte ved man jo at n altid, for en given løsning, er mindre en 42 (eller et andet lille tal).

Martin.

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