Acovea

Acovea implementerer en genetisk algoritme til at finde de "bedste" muligheder for at udarbejde programmer med GCC C og C ++ compilere.
ACOVEA (Analyse af Compiler Options via Evolutionary Algorithm) implementerer en genetisk algoritme til at finde de "bedste" muligheder for at udarbejde programmer med GNU Compiler Collection (GCC) C og C ++ compilere.
"Bedste", i denne sammenhæng defineres som de optioner, der producerer den hurtigste eksekverbare program fra en given kildekode. Acovea er en C ++ ramme, der kan udvides til at teste andre programmeringssprog og ikke-GCC compilere.
Jeg forestiller Acovea som et optimeringsværktøj, ligner i formål til profilering. Traditionelle funktion-niveau profilering identificerer de algoritmer mest indflydelsesrige i et program præstationer; Acovea påføres derefter disse algoritmer til at finde de oversætterflag og valgmuligheder, der genererer den hurtigste kode.
Acovea er også nyttig til at teste kombinationer af flag for pessimistiske interaktioner og til afprøvning af pålideligheden af ​​compileren.
Moderne software er svært at forstå og bekræfte ved traditionelle midler. Millioner af linjer kode producere applikationer indeholder indviklede interaktioner, trodser enkel beskrivelse eller brute-force undersøgelse.
En guidet, deterministisk tilgang til testning afhængig menneskelige testere at forestille alle mulige kombination af foranstaltninger - en urealistisk proposition givet software kompleksitet. Trods denne kompleksitet, vi har brug for svar på vigtige spørgsmål om moderne, store software.
Hvilken slags vigtige spørgsmål? Overvej GNU Compiler Collection. Jeg skriver artikler, som benchmark kode generation, en opgave fyldt med vanskeligheder på grund af de mange muligheder som forskellige compilere. For mine benchmarks for at have nogen mening, jeg har brug for at vide, hvilken kombination af muligheder producerer den hurtigste kode for en given anvendelse.
At finde den "bedste" sæt af muligheder lyder som en simpel opgave, i betragtning af omfanget af GCC dokumentation og den konventionelle visdom GCC udvikler samfundet. Ah, hvis det kun var så nemt! GCC dokumentation, mens omfattende, er også ærligt upræcis.
Jeg værdsætter denne stil dokumentation; i modsætning til mange kommercielle leverandører, der gør absolutte udsagn om "kvaliteten" af deres produkter, GCC er dokumentforfattere indrømme usikkerheder i hvordan forskellige muligheder ændrer kodegenerering. Faktisk, kodegenerering er helt afhængig af hvilken type ansøgning bliver kompileret og målet platform. En mulighed, der producerer hurtig eksekverbar kode til en kildekode kan være til skade for opfyldelsen af ​​et andet program.
"Konventionel visdom" ankommer i min indbakke, når jeg udgiver en ny artikel. Lige fra den høflig til insisterende til det uhøflige, disse e-mails indeholder modstridende forslag til fremstilling af hurtig kode.
I langt de fleste tilfælde, sådanne anekdotiske påstande mangler enhver formelt bevis for deres gyldighed, og, oftere end ikke, den foreslåede "forbedring" er ineffektiv eller skadelig. Det er blevet mere og mere tydeligt, at ingen --myself inkluderet - ved præcist, hvordan alle disse GCC muligheder at arbejde sammen i at generere programkode.
Jeg søger den hellige gral for optimering - men præcis hvad er optimering? Forstå problemet er det første skridt i at finde en løsning.
Optimering forsøg på at fremstille den "bedste" maskinkode fra kildekode. "Bedste" betyder forskellige ting for forskellige applikationer; en database skovle bidder af information, mens en videnskabelig ansøgning beskæftiger sig med hurtige og præcise resultater; den første bekymring for et indlejret system kan være kode størrelse.
Og det er meget muligt, at lille kode er hurtig, eller hurtig kode præcis. Optimering er langt fra at være en eksakt videnskab, da de mange forskellige hardware- og softwarekonfigurationer.
En optimering algoritme kan være så simpelt som at fjerne en løkke invariant eller så komplekst som at undersøge et helt program til at fjerne globale fælles sub-udtryk. Mange optimeringer ændre, hvad programmøren skrev til en mere effektiv form til samme resultat, mens ændre underliggende oplysninger om effektivitet; andre "optimeringer" producere kode, der bruger særlige karakteristika den underliggende hardware, såsom særlige instruktionssæt.
Memory arkitekturer, rørledninger, online- og offline-chip caches - alle påvirke kode præstationer på måder, der ikke er indlysende for programmører bruger et højt niveau sprog. En optimering, der kan synes at producere hurtigere kode kan faktisk skabe store kode, der forårsager flere cache miss, således nedbrydende ydeevne.
Selv den bedste hånd-tunet C-kode indeholder områder af fortolkning; er der ingen absolut, en-til-en overensstemmelse mellem C erklæringer og maskininstruktioner. Næsten enhver sekvens af kildekoden kan opgøres i forskellige - men funktionelt tilsvarende - maskine instruktion vandløb med forskellige størrelser og egenskaber.
Inlining funktioner er et klassisk eksempel på dette fænomen: at erstatte et kald til en funktion med funktionen koden selv kan producere et hurtigere program, men kan også øge programmets størrelse. Øget program størrelse, kan til gengæld forhindre en algoritme fra montering inde højhastigheds-cache-hukommelse, og dermed bremse et program på grund af cache savner.
Læg mærke til min brug af væselord "kan" - må indbygges små funktioner nogle gange tillader andre optimeringsalgoritmer en chance for at forbedre kode til lokale forhold, der producerer hurtigere og mindre kode.
Optimering ikke simpelt eller åbenbar, og kombinationer af algoritmer kan føre til uventede resultater. Hvilket bringer mig tilbage til spørgsmålet: For en given applikation, hvad er de mest effektive optimering muligheder?
Hvad er nyt i denne version:
· Mindre ændringer i den ikke-fri licens.
· Er blevet tilføjet Støtte til de nyeste versioner af libcoyotl og libevocosm.