Acovea

Acovea реалізує генетичний алгоритм для знаходження "кращі" варіанти для компіляції програм з GCC C і C ++ компіляторів.
ACOVEA (аналіз варіантів компілятора через еволюційний алгоритм) реалізує генетичний алгоритм, щоб знайти «найкращі» варіанти компіляції програм з GNU Compiler Collection (GCC) С і компіляторів C ++.
"Кращий", в даному контексті, визначається як тих варіантів, які виробляють найшвидший виконувану програму з даного вихідного коду. Acovea є C ++ структура, яка може бути розширена, щоб перевірити інші мови програмування і не-GCC компілятори.
Я уявляю Acovea як інструмент оптимізації, подібного в цілях профілювання. Традиційний профілювання функції рівня визначає алгоритми найбільш впливових у виконанні програми; Acovea потім застосовується до тих алгоритмів, щоб знайти прапори компілятора і параметри, які генерують найшвидший код.
Acovea також корисно для тестування комбінацій прапорів для песимістичних взаємодій, і для тестування надійності компілятора.
Сучасне програмне забезпечення важко зрозуміти і перевірити за допомогою традиційних засобів. Мільйони рядків коду додатки, що містять виробляти складні взаємодії, всупереч простий опис або перебором розслідування.
Керуючись, детермінований підхід до тестування покладається на людину тестерів уявити собі всі можливі комбінації дій - нереальні пропозиції даного складність програмного забезпечення. Проте, незважаючи на це складнощі, ми потрібні відповіді на важливі питання про сучасний, великомасштабного програмного забезпечення.
Які важливі питання? Розглянемо GNU Compiler Collection. Я пишу статті, які тест генерації коду, завдання пов'язане з труднощами через численні варіантів, передбачених різними компіляторами. Для мої тести, щоб мати який-небудь сенс, мені потрібно знати, яка комбінація варіантів виробляє швидкий код для цього додатка.
Пошук "кращий" набір опцій звучить як просте завдання, враховуючи ступінь GCC документації і звичайні мудрість спільноти розробників GCC. Ах, якби це було тільки так просто! Документація GCC, в той час як великий, також чесно неточним.
Я ціную цей стиль документації; на відміну від багатьох комерційних постачальників, які роблять абсолютні заяви про «якість» їх продукції, письменників документації GCC визнають невизначеності в тому, як різні варіанти змінюють генерацію коду. Дійсно, генерації коду, повністю залежить від типу застосування скомпільованого і цільової платформи. Варіант, який виробляє швидкий виконуваний код для одного вихідного коду може бути шкідливим для виконання іншої програми.
"Здоровий глузд" прибув до моєї поштової скриньки, коли я публікую нову статтю. Починаючи від ввічливим наполегливий у грубий, ці електронні листи містять суперечливі пропозиції для отримання швидкого коду.
У переважній більшості випадків, такі анекдотичні твердження не мають ніякого формального докази їх обґрунтованості, і, найчастіше, запропонував "покращення" неефективно або шкідливим. Це стає все більш очевидним, що жоден --myself включений - точно не знає, як всі ці варіанти GCC працювати разом в генерації коду програми.
Я шукаю Святий Грааль оптимізація - але саме те, що оптимізація? Розуміння проблеми є першим кроком у пошуку рішення.
Оптимізація намагається справити "кращий" машинний код з вихідного коду. "Кращий" означає різні речі для різних додатків; а лопати баз даних шматки інформації, в той час як науково додатки, пов'язані з швидким і точним результатам; Перша турбота для вбудованих систем можуть бути розмір коду.
І це цілком можливо, що невеликий код швидко, або код швидкого точним. Оптимізація далеко не точна наука, враховуючи різноманітність апаратних і програмних конфігурацій.
Алгоритм оптимізації може бути як простий, як видалення інваріант циклу, або ж складним, як вивчення цілу програму, щоб усунути глобальні загальні подвираженія. Багато оптимізації змінити те, що програміст написав у більш ефективній формі, виробляти той же результат, а змінюючи, що лежать в основі деталей для підвищення ефективності; інший "оптимізації" продукція код, який використовує специфічні характеристики використовуваного обладнання, такі як спеціальні набори інструкцій.
Архітектури пам'яті, трубопроводи, включення і відключення чіпа кешируєт - все це впливає на продуктивність коду способами, які не очевидні для програмістів, що використовують мову високого рівня. Оптимізації, може здатися, щоб провести швидкий код може, насправді, створити великий код, який викликає більше промахів, тим самим зниження продуктивності.
Навіть найкраща рука налаштовані код С містить області інтерпретації; немає абсолютної, один-на-однозначна відповідність між Із заявами і машинних інструкцій. Майже будь-яка послідовність вихідного коду можуть бути скомпільовані в різні - але функціонально еквівалентні - машинна потоків з різними розмірами і характеристиками.
Вбудовування функцій є класичним прикладом цього явища: заміна виклику функції з кодом функції самого можуть виробляти більш швидкий програму, але також може збільшити розмір програми. Збільшення розміру програми, можуть, у свою чергу, запобігає алгоритм прилеганию всередині високошвидкісний кеш-пам'яті, таким чином, сповільнюючи програму через кеш-промахів.
Зверніть увагу, моє використання ласки слово "може" - вбудовування невеликих функцій дозволяє іноді інші алгоритми оптимізації шанс для подальшого поліпшення коду для місцевих умов, створюючи швидше і менше коду.
Оптимізація не просто або очевидно, і комбінації алгоритмів може призвести до несподіваних результатів. Це повертає мене до питання: Для будь-якого даного додатки, які найбільш ефективні варіанти оптимізації?
Що нового в цій версії:
· Незначні зміни в невільною ліцензією.
· Додана підтримка для останніх версій libcoyotl і libevocosm.