Acovea

Acovea genomför en genetisk algoritm för att hitta de "bästa" alternativ för att sammanställa program med GCC C och C ++ kompilatorer.
ACOVEA (Analys av kompilatoralternativ via Evolutionary algoritm) genomför en genetisk algoritm för att hitta de "bästa" alternativ för att sammanställa program med GNU Compiler Collection (GCC) C och C ++ kompilatorer.
"Bästa" i detta sammanhang, definieras som de alternativ som producerar den snabbaste körbara programmet från en given källkoden. Acovea är en C ++ ramverk som kan utökas för att testa andra programmeringsspråk och icke-GCC kompilatorer.
Jag ser framför Acovea som ett optimeringsverktyg, liknande syfte till profilering. Traditionell funktionsnivå profilering identifierar de algoritmer mest inflytelserika i ett program prestanda; Acovea sedan tillämpas på de algoritmer för att hitta de kompilatorflaggor och alternativ som genererar den snabbaste koden.
Acovea är också användbar för att testa kombinationer av flaggor för pessimistiska interaktioner, och för att testa tillförlitligheten av kompilatorn.
Modern programvara är svårt att förstå och på traditionellt sätt kontrollera. Miljontals kodrader producera program som innehåller intrikata samspel, trotsar enkel beskrivning eller brute-force utredning.
En guidad, deterministiska syn på testning bygger på mänskliga testare att föreställa sig alla möjliga kombination av åtgärder - en orealistisk proposition ges programvara komplexitet. Men trots denna komplexitet, behöver vi svar på viktiga frågor om modern, storskalig programvara.
Vilken typ av viktiga frågor? Tänk på GNU Compiler Collection. Jag skriver artiklar som riktmärke kodgenerering, en uppgift förenat med svårigheter på grund av de otaliga möjligheter som olika kompilatorer. För mina riktmärken för att ha någon mening, jag behöver veta vilken kombination av optioner ger den snabbaste kod för en given tillämpning.
Att hitta den "bästa" uppsättning alternativ låter som en enkel uppgift med tanke på omfattningen av GCC dokumentation och den konventionella visdomen i GCC utvecklare. Ah, om det bara var så lätt! GCC dokumentation, medan omfattande, är också ärligt oprecis.
Jag uppskattar denna typ av dokumentation; Till skillnad från många kommersiella leverantörer, som gör absoluta uttalanden om "kvalitet" på sina produkter, GCC: s dokumentationsförfattare erkänna osäkerheter i hur olika alternativ ändrar kodgenerering. I själva verket är kodgenerering helt beroende på vilken typ av ansökan sammanställs och målplattform. Ett alternativ som ger snabb exekverbar kod för en källkod kan vara skadligt för utförandet av ett annat program.
"Konventionell visdom" kommer i min inkorg när jag publicerar en ny artikel. Allt från artigt att det enträgna till oförskämd, dessa e-postmeddelanden innehåller motstridiga förslag för att producera snabbt kod.
I de allra flesta fall, sådana anekdotiska påståenden saknar intyg deras giltighet, och oftare än inte, är den föreslagna "förbättring" ineffektiva eller skadliga. Det har blivit alltmer uppenbart att ingen --myself ingår - vet exakt hur alla dessa GCC alternativ fungerar tillsammans för att generera programkod.
Jag söker den heliga graal för optimering - men exakt vad är optimering? Förstå problemet är det första steget i att hitta en lösning.
Optimering Försök att framställa den "bästa" maskinkod från källkoden. "Bästa" betyder olika saker för olika tillämpningar; en databas spadar bitar av information, medan en vetenskaplig ansökan sysslar med snabba och korrekta resultat; ledordet för ett inbyggt system kan vara kodstorleken.
Och det är fullt möjligt att liten kod är snabb eller snabb kod exakt. Optimering är långt ifrån en exakt vetenskap, med tanke på mångfalden av maskinvara och programvara.
En optimeringsalgoritm kan vara så enkelt som att ta bort en slinga invariant, eller så komplicerat som att undersöka ett helt program för att eliminera globala gemensamma under uttryck. Många optimeringar ändra vad programmeraren skrivit till en mer effektiv form leda till samma resultat samtidigt förändra underliggande information om effektivitet; andra "optimeringar" producerar kod som använder särdrag den underliggande hårdvaran, såsom särskilda instruktionsuppsättningar.
Minnes arkitekturer, rörledningar, on- och off-chip cachar - allt påverkar kod prestanda på ett sätt som inte är självklart för programmerare med en högnivåspråk. En optimering som kan tyckas att producera snabbare kod kan i själva verket skapa stor kod som orsakar mer cachemissar, vilket förnedrande prestanda.
Även den bästa handen-tuned C-kod innehåller områden tolknings; det finns ingen absolut, en-till-en motsvarighet mellan C uttalanden och maskininstruktioner. Nästan varje sekvens av källkoden kan kompileras till olika - men funktionellt likvärdig - maskin instruktion strömmar med olika storlekar och prestandaegenskaper.
Inlining funktioner är ett klassiskt exempel på detta fenomen: att ersätta ett anrop till en funktion med funktionskoden själv kan ge en snabbare program, men kan också öka rambelopp. Ökad rambelopp, kan i sin tur hindra en algoritm från montering inuti höghastighets cacheminne, vilket fördröjer ett program på grund av cachemissar.
Lägg märke till min användning av vesslan ordet "får" - inlining små funktioner ibland tillåter andra optimeringsalgoritmer en chans att ytterligare förbättra koden för lokala förhållanden, producerar snabbare och mindre kod.
Optimering är inte enkel eller uppenbar, och kombinationer av algoritmer kan leda till oväntade resultat. Vilket leder mig tillbaka till frågan: För varje given tillämpning, vilka är de mest effektiva optimeringsalternativ?
Vad är nytt i den här versionen:
· Mindre förändringar i icke-fri licens.
· Stöd har lagts till för de senaste versionerna av libcoyotl och libevocosm.