Acovea

Acovea implementeer 'n genetiese algoritme vir die vind van die "beste" opsies vir die opstel van programme met die GCC C en C ++ samestellers.
ACOVEA (Ontleding van Compiler Options via Evolusionêre Algoritme) implementeer 'n genetiese algoritme om die "beste" opsies vir die opstel van programme met die GNU Compiler Collection (GCC) C en C ++ opstellers vind.
"Beste", in hierdie konteks, word gedefinieer as die opsies wat die vinnigste uitvoerbare program van 'n gegewe bronkode te produseer. Acovea is 'n C ++ raamwerk wat uitgebrei kan word na ander programmeertale en nie-GCC opstellers toets.
Ek sien 'Acovea as 'n optimalisering instrument, soortgelyk in doel om profiele. Tradisionele funksie-vlak profilering identifiseer die algoritmes mees invloedryke in prestasie 'n program se; Acovea word dan toegepas op diegene algoritmes die samesteller vlae en opsies wat die vinnigste kode genereer vind.
Acovea is ook nuttig vir die toets van kombinasies van vlae vir pessimisties interaksies, en vir die toets van die betroubaarheid van die samesteller.
Moderne sagteware is moeilik om te verstaan ​​en te verifieer deur die tradisionele wyse. Miljoene reëls van die kode produseer aansoeke wat ingewikkelde interaksies, verontagsaming eenvoudige beskrywing of brute krag ondersoek.
'N begeleide, deterministiese benadering tot toetsing berus op menslike testers om elke moontlike kombinasie van aksies visies - 'n onrealistiese stelling gegee sagteware kompleksiteit. Tog, ten spyte van dat kompleksiteit, moet ons die antwoorde op belangrike vrae oor die moderne, grootskaalse sagteware.
Watter soort van belangrike vrae? Oorweeg die GNU Compiler Collection. Ek skryf artikels wat maatstaf kode geslag, 'n taak belaai met probleme as gevolg van die talle opsies wat deur verskillende samestellers. Vir my maatstawwe om enige betekenis hê, moet ek weet watter kombinasie van opsies die vinnigste kode produseer vir 'n gegewe aansoek.
Dit vind van die "beste" stel opsies klink soos 'n eenvoudige taak nie, gegewe die omvang van GCC dokumentasie en die konvensionele wysheid van die GCC ontwikkelaar gemeenskap. Ag, al was dit maar so maklik! Die GCC dokumentasie, terwyl uitgebreide, is ook eerlik vaag.
Ek waardeer hierdie styl van dokumentasie; In teenstelling met baie kommersiële verskaffers, wat maak absolute uitsprake oor die "kwaliteit" van hul produkte, GCC se Documenta erken onsekerhede in hoe verskeie opsies te verander kodegenerasie. Inderdaad, kodegenerasie is heeltemal afhanklik van die aard van die aansoek word saamgestel en die teiken platform. 'N opsie wat vinnig uitvoerbare kode produseer vir een bron-kode kan nadelig vir die prestasie van 'n ander program.
"Konvensionele wysheid" kom in my inbox wanneer ek publiseer 'n nuwe artikel. Wat wissel van die beleefde die aanhoudend om die onbeskofte, hierdie e-posse bevat teenstrydige voorstelle vir die vervaardiging van 'n vinnige-kode.
In die oorgrote meerderheid van gevalle, soos anekdotiese bewerings gebrek aan enige formele bewys van die geldigheid, en meer dikwels as nie, die voorgestelde "verbetering" is oneffektief of skadelik. Weet presies hoe al hierdie GCC opsies saamwerk in die opwekking van program-kode - Dit het toenemend duidelik dat niemand --myself ingesluit word.
Ek soek die Heilige Graal van Optimization - maar presies wat optimization? Begrip van die probleem is die eerste stap in die vind van 'n oplossing.
Optimalisering pogings om die "beste" masjien-kode van die bron-kode te produseer. "Beste" beteken verskillende dinge vir verskillende toepassings; 'n databasis skoppe stukke van inligting, terwyl 'n wetenskaplike toepassing is gemoeid met 'n vinnige en akkurate resultate; die eerste bekommernis vir 'n geïntegreerde stelsel code grootte wees.
En dit is heel moontlik dat klein-kode is vinnig, of vinnig-kode akkuraat. Optimalisering is ver van 'n presiese wetenskap, gegewe die diversiteit van hardeware en sagteware konfigurasies.
'N optimeringsalgoritme kan so eenvoudig wees soos die verwydering van 'n lusinvariant, of so kompleks as die ondersoek 'n hele program om globale algemene sub-uitdrukkings uit te skakel. Baie optimalisaties verander wat die programmeerder geskryf in 'n meer doeltreffende vorm, die vervaardiging van dieselfde resultaat terwyl verander onderliggende besonderhede vir doeltreffendheid; ander "optimalisaties" produseer kode wat spesifieke eienskappe van die onderliggende hardeware, soos spesiale opdrag stelle gebruik.
Memory argitekture, pyplyne, op-en af-chip caches - al raak kode prestasie op wyses wat nie voor die hand liggend te programmeerders met behulp van 'n hoë-vlak taal. 'N optimalisering wat kan lyk om vinniger kode produseer kan, in werklikheid, skep groot kode wat meer kas mis veroorsaak, dus vernederende prestasie.
Selfs die beste hand ingeskakel C-kode bevat gebiede van interpretasie; daar is geen absolute, een-tot-een ooreenkoms tussen C state en masjien instruksies. Byna enige volgorde van die bron-kode kan word saamgestel in verskillende - maar funksioneel ekwivalent - masjien instruksies strome met verskillende groottes en prestasie eienskappe.
Inlining funksies is 'n klassieke voorbeeld van hierdie verskynsel: 'n oproep om 'n funksie te vervang met die funksie code self kan 'n vinniger program te produseer nie, maar kan ook verhoog grootte program. Groter program, kan op sy beurt, verhoed 'n algoritme van pas binne 'n hoë-spoed kasgeheue, dus 'n program stadiger as gevolg van die kas mis.
Let my gebruik van die mol woord "mag" - inlining klein funksies kan soms ander optimeringsalgoritmes 'n kans om verder te verbeter kode vir plaaslike toestande, die vervaardiging van vinniger en kleiner code.
Optimalisering is nie eenvoudig of voor die hand liggend, en kombinasies van algoritmes kan lei tot onverwagte resultate. Dit bring my terug na die vraag: Vir enige gegewe aansoek, wat is die mees doeltreffende optimalisering opsies?
Wat is nuut in hierdie release:
· Geringe veranderinge in die nie-vrye lisensie.
· Ondersteuning is bygevoeg vir die nuutste weergawes van libcoyotl en libevocosm.