Acovea

Acovea изпълнява генетичен алгоритъм за намиране на "добрите" опции за съставяне на програми с GCC C и C ++ компилатори.
ACOVEA (Анализ на Compiler Options чрез еволюционна алгоритъм), се изпълнява на генетичен алгоритъм, за да намерите най-добрите "" възможностите за съставяне на програми с GNU Compiler Collection (GCC) С и С ++ компилатори.
"Най-добър", в този контекст, се определя като онези възможности, които произвеждат най-бързо изпълнима програма от даден код. Acovea е ++ рамка C, която може да бъде разширена, за да тествате различни програмни езици и компилатори не-ССЗ.
Представям Acovea като инструмент за оптимизиране, подобен по предназначение за профилиране. Традиционна профилиране функция ниво идентифицира алгоритмите най-влиятелните в изпълнение на дадена програма; След Acovea се прилага към тези алгоритми, за да намерите най-знамената съставител и опциите, които генерират най-бързият код.
Acovea Също така е полезно за тестване на комбинации от флагове за песимистичните взаимодействия, както и за проверка на надеждността на компилатора.
Modern софтуер е трудно да се разбере и да се провери с традиционни средства. Милиони реда код произвеждат приложения, съдържащи сложни взаимодействия, противодействие просто описание или разследване груба сила.
Обиколка, детерминиран подход за тестване разчита на човешките тестери да си представим всяка възможна комбинация от действия - едно нереалистично предложение даден софтуер сложност. И все пак, въпреки, че сложността, имаме нужда отговори на важни въпроси за модерна, мащабна софтуер.
Какви важни въпроси? Помислете Compiler Collection на GNU. Аз пиша статии, които бенчмарк генериране на код, задача, изпълнен с трудности, дължащи се на безбройните възможности, предоставяни от различни компилатори. За моите критерии да има някакъв смисъл, аз трябва да знам коя комбинация от възможности произвежда най-бързият код за дадено приложение.
Намирането на "най-добрите" набор от опции звучи като проста задача, като се има предвид степента на GCC документация и конвенционалната мъдрост на общността на разработчиците GCC. Ах, ако беше само толкова лесно! Документацията на GCC, докато обширна, също е честно неточно.
Оценявам този стил на документация; за разлика от много търговски доставчици, които правят абсолютни твърдения за "качеството" на своите продукти, documenters ССПЗ признават неясноти в това как различните опции променят генериране на код. Наистина, генериране на код е изцяло зависим от вида на приложението, които да бъдат съставени и целевата платформа. Допълнително устройство, което произвежда бързо изпълним код за един изходен код може да бъде в ущърб на изпълнението на друга програма.
"Конвенционална мъдрост" пристига в моята пощенска кутия всеки път, когато публикувате нова статия. Вариращи от любезен с настойчивите до груб, тези електронни съобщения съдържат противоречиви предложения за производство на бърза код.
В по-голямата част от случаите, тези анекдотични твърдения липсва официално доказателство за тяхната валидност, и, по-често, отколкото не, предложеното "подобрение" е неефективна или вредна. Става все по-очевидно, че никой не --myself включени - знае точно как всички тези ССЗ опции работят заедно при създаването на програмен код.
Търся Светия Граал на Optimization - но точно това е оптимизация? Разбиране на проблема е първата стъпка в намирането на решение.
Оптимизация опитва да произвежда "най-добрата" машинен код от изходния код. "Най-добър" означава различни неща за различните приложения; а лопати бази данни парчета от информация, а научно използване е свързано с бързи и точни резултати; първата грижа за вградена система може да бъде размера на код.
И това е напълно възможно, че малък код е бърз, или бързо код точна. Оптимизация далеч не е точна наука, като се има предвид разнообразието на хардуерни и софтуерни конфигурации.
Алгоритъм за оптимизация може да бъде толкова просто като отстраняване на една линия инвариант, или толкова сложна, колкото разглеждането на цялата програма за премахване на глобалните общи под-изрази. Много оптимизации променят това, което програмистът е написал в една по-ефективна форма, доведе до същия резултат, докато се променя основните детайли за ефективност; други "оптимизации" продукция код, който използва специфични характеристики на хардуера, като например специални комплекти с инструкции.
Архитектури памет, тръбопроводи, онлайн и офлайн чип кеш - всички засегнат код на ефективността по начини, които не са очевидни за програмисти, използващи езика на високо равнище. Една оптимизация, че може да изглежда да произвеждат по-бързо код може в действителност да създаде голям код, който причинява повече кеш пропуска, като по този начин унизително представяне.
Дори и най-добрата ръка настроени C код съдържа области на тълкуване; няма абсолютно едно към едно съответствие между изявления C и машинни инструкции. Почти всяка последователност от изходния код може да бъде компилиран в различна - но функционално еквивалентен - машинна инструкция потоци с различни размери и характеристики.
Вграждането функции е класически пример за това явление: подмяна на повикване към функция с самия код на функция може да доведе до по-бързо програма, но може също така да увеличи размера на програмата. Увеличен размер на програма, може, на свой ред, за предотвратяване на алгоритъм от монтиране вътре високоскоростен кеш памет, като по този начин забавя програма поради кеш пропуска.
Забележете моята употреба на невестулка думата "може" - Вграждането малки функции понякога позволява на други алгоритми за оптимизация шанс за по-нататъшно подобряване на код за местните условия, произвеждащи по-бързо и по-малък код.
Оптимизация не е проста или явна, и комбинации от алгоритми може да доведе до неочаквани резултати. Което ме връща на въпроса: За всяко дадено приложение, кои са най-ефективни варианти за оптимизация?
Какво е новото в тази версия:
· Незначителни промени в несвободен лиценз.
· Добавена е поддръжка за най-новите версии на libcoyotl и libevocosm.