Acovea

Acovea實現了遺傳算法尋找“最佳”選項編譯與海灣合作委員會的C和C ++編譯器程序。
ACOVEA（通過進化算法編譯器選項分析）實現了遺傳算法來找到“最好”的編譯選項與GNU編譯器集合（GCC）的C和C ++編譯器程序。
“最佳”，在這種情況下，被定義為那些產生從一個給定源代碼最快可執行程序的選項。 Acovea是可以擴展到測試其他的編程語言和非GCC編譯一個C ++框架。
我設想Acovea作為優化工具，在目的上分析相似。傳統的功能層次分析識別算法，最有影響力的一個程序的性能; Acovea，然後應用到那些算法來發現產生最快代碼編譯器標誌和選項。
Acovea也用於測試的標誌的組合悲觀的相互作用，以及用於測試編譯器的可靠性是有用的。
現代軟件是很難理解和驗證通過傳統方式。數百萬行的代碼產生含有複雜交互的應用程序，不畏簡單的描述或蠻力調查。
在導遊帶領下，確定性的測試方法依賴於人的測試設想的行動，每一個可能的組合 - 給定的軟件複雜性的一個不切實際的主張。然而，儘管複雜，我們需要回答關於現代，大型軟件的重要問題。
有什麼重要的問題排序？考慮GNU編譯器集合。我寫的文章，基準代碼生成，任務困難重重，由於不同的編譯器所提供的無數的選擇。對於我的標準有什麼意義，我需要了解哪些選項組合產生速度最快的代碼，一個給定的應用。
尋找“最佳”選項集聽起來像一個簡單的任務，因為GCC文檔的程度和GCC開發者社區的傳統智慧。嗯，如果只是這麼簡單！ GCC的文檔，而廣泛的，也是老老實實不精確。
我很欣賞這種風格文件;不像許多商業供應商，誰做絕對陳述自己的產品的“質量”，海灣合作委員會的資料員承認在不確定性，如何把不同選項來改變代碼生成。實際上，代碼生成是完全依賴於應用的被編譯的類型和目標平台。產生快速的可執行代碼對一個信號源代碼的選項可能是有害的另一個程序的性能。
“傳統智慧”在我的收件箱到達每當我發布一個新的文章。從禮貌的堅持到粗魯，這些電子郵件包含生產快速代碼矛盾的建議。
在案件的絕大多數，這種傳聞斷言缺乏其有效性的任何正式的證據，而且，往往不是，建議“改進”是無效或有害的。它已成為越來越明顯的是沒有一個人--myself包括 - 確切地知道如何將所有這些GCC選項共同努力生成的程序代碼。
我尋求優化的聖杯 - 但到底什麼是優化？理解這個問題是找到解決辦法的第一步。
優化試圖產生從源代碼的“最佳”的機器代碼。 “最佳”是指不同的事情，不同的應用;的信息的數據庫鏟塊，而一個科學應用涉及快速和精確的結果;對於嵌入式系統首先要關注的可能是代碼的大小。
它很可能是小的代碼是快，快碼準確。優化遠非一種精確的科學，因為硬件和軟件配置的多樣性。
優化算法可以很簡單，比如去掉一個循環不變的，複雜的如檢查整個程序，以消除全球通用的子表達式。很多優化改變什麼程序員寫為更有效的形式，而製造底層改變細節的效率相同的結果;使用基礎硬件的具體特點，如特殊指令集等“優化”產生代碼。
內存體系結構，管道，導通和關斷芯片的高速緩存 - 所有影響的方式是不明顯使用高級語言編程代碼的性能。優化的可能似乎產生更快的代碼可能，實際上，創建大型的代碼，導致更多的緩存未命中，從而降低性能。
即使是最好的手工調整的C代碼包含解釋領域;沒有絕對的，一對一的C語句和機器指令之間的對應關係。幾乎源代碼的任何序列可被編譯為不同的 - 但功能上等同的 - 機器指令具有不同的尺寸和性能特性流。
內聯函數是這種現象的一個典型的例子：更換電話與功能的代碼本身可能會產生更快的程序功能，而且還可能會增加程序的大小。增加程序大小，可反過來防止算法從內部高速緩存存儲器嵌合，從而由於高速緩存未命中的程序放緩。
請注意我用的詞黃鼠狼“可能” - 內聯小函數有時允許其他優化算法有機會進一步改善當地條件的代碼，生產速度更快，更小的代碼。
優化並不簡單或明顯，算法組合可能會導致意想不到的結果。這使我回到了一個問題：對於任何給定的應用程序，什麼是最有效的優化選項？
什麼是新的，在此版本：
·在非自由許可證的微小變化。
·支持已經增加了對libcoyotl和libevocosm的最新版本。