Acovea

Acovea toteuttaa geneettisen algoritmin löytää "paras" vaihtoehtoja kokoamiseen ohjelmien GCC C ja C ++ kääntäjät.
ACOVEA (analyysi Compiler Options kautta Evoluutioalgoritmin) toteuttaa geneettisen algoritmin löytää "paras" vaihtoehtoja kokoamiseen ohjelmien gcc (GCC) C ja C ++ kääntäjät.
"Paras", tässä yhteydessä, on määritelty kuten ne vaihtoehdot, jotka tuottavat nopeimmin suoritettava ohjelma annetusta lähdekoodista. Acovea on C ++: kehys, jota voidaan laajentaa testata muita ohjelmointikieliä ja ei-GCC kerääjiä.
I kuvitella Acovea kuin optimointityökalu, samanlainen tarkoitus profilointiin. Perinteiset toiminto-tason profilointi tunnistaa algoritmit vaikutusvaltaisin ohjelman suorituskykyä; Acovea sovelletaan sitten näitä algoritmeja löytää kääntäjä liput ja vaihtoehtoja, jotka tuottavat nopein koodin.
Acovea on hyödyllinen myös testattaessa yhdistelmiä lippuja pessimistinen vuorovaikutusta, ja testaukseen luotettavuuden kääntäjä.
Moderni ohjelmisto on vaikea ymmärtää ja todentaa perinteisin keinoin. Miljoonia rivejä koodia tuottaa sovelluksia, jotka sisältävät monimutkaisia ​​vuorovaikutuksia, uhmaten yksinkertainen kuvaus tai raakaa voimaa tutkimus.
Opastettu, deterministinen lähestymistapa testaukseen perustuu ihmisen testaajia kuvitella kaikki mahdolliset toimien yhdistelmää - epärealistinen ehdotus annetaan ohjelmistojen monimutkaisuus. Silti, vaikka se monimutkaisuus, meidän vastauksia tärkeisiin kysymyksiin moderni, laajamittainen ohjelmisto.
Minkälainen tärkeitä kysymyksiä? Harkitse GNU Compiler Collection. Kirjoitan artikkeleita, että vertailukohtana koodin generointi, tehtävä paljon ongelmia, koska lukemattomia vaihtoehdoista eri kääntäjät. Minun vertailukohtia olisi mitään merkitystä, minun täytyy tietää, mitkä vaihtoehtojen yhdistelmä tuottaa nopein koodin tietyn sovelluksen.
Löytää "paras" asetuksetkin kuulostaa yksinkertainen tehtävä, kun otetaan huomioon laajuus GCC asiakirjat ja perinteisen viisauden GCC kehittäjäyhteisö. Ah, jos se oli vain niin helppoa! GCC asiakirjat, kun taas laaja, on myös rehellisesti epätarkka.
Arvostan tätä tyyliä dokumentoinnin; toisin kuin monet kaupalliset toimittajat, jotka tekevät absoluuttinen lausuntoja "laatu" niiden tuotteiden, GCC: n documenters myöntävät epävarmuustekijät, miten eri vaihtoehdot muuttaa koodin generointi. Todellakin, koodin generointi on täysin riippuvainen tyypistä hakemuksen koottu ja Kohdeympäristö. Vaihtoehto, joka tuottaa nopeita koodia yhden lähdekoodi saattaa olla haitallista suorituskykyä toisen ohjelman.
"Perinteiset viisaus" saapuu omaan postilaatikkoon aina kun julkaista uusi artikkeli. Vaihtelevat kohteliasta itsepintaisesti on töykeä, nämä sähköpostit sisältävät ristiriitaisia ​​ehdotuksia tuottamiseen nopeasti koodin.
Suurimmassa osassa tapauksia, kuten sattumanvaraisia ​​väitteet ole mitään virallisia todisteita niiden pätevyyttä, ja useammin kuin ei, ehdotti "parannus" on tehoton tai haitallista. Se on tullut yhä ilmeisemmäksi, että kukaan --myself sisälly - tietää tarkasti, miten kaikki nämä GCC vaihtoehdot toimivat yhdessä tuottaa ohjelmakoodin.
Etsin Graalin malja Optimization - mutta mitä on optimointi? Ymmärtäminen ongelma on ensimmäinen askel löytää ratkaisun.
Optimointi pyrkii tuottamaan "paras" konekoodi lähdekoodista. "Best" tarkoittaa eri asioita eri sovelluksiin; tietokanta lapiot paloina tiedon, kun tieteellinen sovellus koskee nopeita ja tarkkoja tuloksia; ensimmäinen huolenaihe sulautettuun järjestelmään saattaa olla koodin koko.
Ja on täysin mahdollista, että pieni koodi on nopea tai nopea koodin tarkka. Optimointi on kaukana eksakti tiede, koska monimuotoisuus laitteiden ja ohjelmistojen kokoonpanoissa.
Optimointialgoritmi voi olla niinkin yksinkertainen kuin poistamalla silmukan muuttumaton, tai monimutkainen kuin tarkastellaan koko ohjelman poistaa maailmanlaajuista yhteistä sub-ilmaisuja. Monet optimointi muuttaa sitä, mitä ohjelmoija kirjoitti tulee tehokkaampi muoto, samaan tulokseen samalla muuttamatta taustalla olevia yksityiskohtia tehokkuutta; muut "optimointi" tuottaa koodin, joka käyttää erityispiirteet taustalla laitteisto, kuten erityisiä käskykantoja.
Muisti arkkitehtuurit, putkistot, on- ja off-chip välimuistit - kaikki vaikuttavat koodin suorituskykyyn tavoilla, jotka eivät ole ilmeisiä ohjelmoijat käyttämällä korkean tason kieli. Optimointi, joka voi näyttää tuottaa nopeammin koodia voivat itse asiassa luoda suuria koodia, joka aiheuttaa enemmän välimuisti piti, mikä halventava suorituskykyä.
Paraskaan käsin viritetty C koodi sisältää alueita tulkinnan; ei ole ehdoton, yksi-yhteen vastaavuus C lausuntojen ja koneen ohjeita. Lähes mikä tahansa sekvenssi lähdekoodia voidaan kootaan eri - mutta toiminnallisesti vastaava - konekäskyjen puroihin eri kokoja ja suoritusarvot.
Upottamalla toiminnot on klassinen esimerkki tästä ilmiöstä: korvataan kutsu toiminnon toimintokoodi itse voi tuottaa nopeamman ohjelmaa, vaan saattavat myös lisätä ohjelman kokoa. Lisääntynyt ohjelma koko, voi puolestaan ​​estää algoritmin asettumasta sisältä nopea välimuisti, mikä hidastaa ohjelman takia välimuistiin osu.
Huomatkaa käyttö lumikko sana "voi" - upottamista pieni toiminnot joskus mahdollistaa muiden algoritmit mahdollisuus edelleen parantaa koodin paikalliset olosuhteet, jotka tuottavat nopeampia ja pienempiä koodia.
Optimointi ei ole yksinkertainen tai ilmeisiä, ja yhdistelmät algoritmeja voi johtaa odottamattomiin tuloksiin. Tästä pääsenkin takaisin kysymykseen: Tietyn sovelluksen, mitkä ovat tehokkaimmat optimointi vaihtoehtoja?
Mitä uutta tässä julkaisussa:
· Pieniä muutoksia ei vapautettu.
· Tuki on lisätty uusimmat versiot libcoyotl ja libevocosm.