Previous Entry Share Next Entry
2016-01

Про правильные методы оптимизации и генерации софта

https://github.com/eschkufz/stoke-release


beginning from binaries compiled by llvm -o0 for 64-bit x86, our prototype implementation, stoke, is able to produce programs which either match or outperform the code produced by gcc -o3, icc -o3, and in some cases, expert handwritten assembly.


Не, понятное дело что для больших программ это не годится. И для мест, где важна корректность - тоже.

Но, эммм, что-то мне этот суровый инженерный подход кажется жизнеспособным гораздо больше, чем лабораторные изыски, как показал прошлогодний ICFPC.

This entry was originally posted at http://wizzard.dreamwidth.org/391942.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
kunaifusu September 24th, 2014
У Нвидии был такой компилятор шейдеров для ps3 что вставляя 0+ и 1* в разных местах можно было получить сильно разный код и Сони добавила ключ который, получив сил, рандомно их добавлял. Ну и у всех в тулчейне была возможность перебоа этих сидов. На выходные бывало запустишь, в понедельник игра на 10% быстрее!

wizzard0 September 25th, 2014
Ага, слышал про такое.

Тут впрочем достаточно креативный брутфорсер, там в пейпере оно например DoF в рейтрейсере выоптимизировало нафиг, когда допустимую погрешность повысили.

mbr September 25th, 2014
Я уже как-то писал, что режим o3 нерабочий у gcc 4. Вплоть до гейзенбагов компилятора. Лучше бы вместо понтов мануалы читали.

http://mbr.livejournal.com/399311.html

Ассемблер тоже спорный момент. Не знаю как в x86, но в арме компилятор в качестве генерации ассемблерного кода уже превзошел высер среднего программиста.

wizzard0 September 25th, 2014
Я помню про o3. Но они проверяют корректность получившихся бинарей, если что.

mbr September 25th, 2014
И вообще, сделают для АРМа, будет интересно посмотреть. Хотя, там уже, на мое имхо заоптимизировано до нельзя на уровне архитектуры. А так... такое ощущение, что писалось для каких-нибудь брутфорсеров, больше мне в голову ничего не приходит, чтобы это было небольшим и супероптимизированным.

wizzard0 September 25th, 2014
Рынок математического моделирования очень даже рынок, например.

mbr September 25th, 2014
Мой подход такой - есть деньги - делай в железе, там гарантированный результат.

sleepy_drago September 25th, 2014
случайный поиск инструкций может помочь если инструкции это ограничивающий фактор. Тысячу флажков в логике и расположение в кеше это исправить не может вроде как никогда. И факторы в порядке важности 1)сложность алгоритма 2)расположение в памяти 3)ветвления/срывы конвейера 4)... тут может быть их реклама =)

wizzard0 September 25th, 2014
ветвления они как раз могут порешать, во всяком случае из других пейперов понятно, что работают над этим.

sorhed September 25th, 2014
ВО СЛАВУ ХАОСА!!!!111

_winnie September 25th, 2014
Если посадить очень много обезьянок оптимизировать программу...

justy_tylor September 25th, 2014
Мне кажется более толковым подход equality saturation. Туда бы ещё аллокацию регистров и процессорных блоков без комбинаторного взрыва протянуть - было бы совсем счастье, прямо в код целевой платформы.

wizzard0 September 25th, 2014
> equality saturation

В пейпере довольно подробно описано, почему equality saturation не работает :(

justy_tylor September 25th, 2014
Там есть лишь одно возражение, "слишком зависит от expert knowledge". Но особенности работы команд add или lea на процессоре - тоже expert knowledge. Никто не мешает выводить из имеющихся аксиом новые оптимизации прямо по ходу работы, а также осуществлять их тестирование и мемоизацию или постоянное хранение в датасетах.

wizzard0 September 25th, 2014
Expert knowledge это как раз не проблема.

> выводить из имеющихся аксиом новые оптимизации прямо по ходу работы
Вот это - проблема.

Это не "аксиомы", это anecdotal evidence which does not compose.

  • 1
?

Log in

No account? Create an account