Существует ли тулза автоматизирующая (хотя бы частично) процесс оптимизации программы?

Существует ли тулза автоматизирующая (хотя бы частично) процесс оптимизации ассемблерного листинга (или исполняемого файла) под любой указанный процессор семейства x86? Под оптимизацией я здесь подразумеваю к примеру изменение порядка следования команд не влияющее на функционирование программы, но позволяющее увеличить скорость ее работы и т.д. и т.п.

 

И, по ходу дела, еще один вопрос: обрабатывают ли оптимизирующие компиляторы ЯВУ содержимое ассемблерных вставок, или оно остается не изменным (т.е. как написано так и будет)?

 

Oleg_SK



Да. есть, называется - голова.

Разбираешь каждый блок и сам анализируешь как тебе лучше, а всех вариантов ниодна тузла не обработает !

Есть хорошие статьи, например - Агнер Фог.

Удачи.

 

svl

Пытаешься издеваться, да? Я не говорю, что не способен сам оптимизировать программу. Я просто хочу знать, есть ли возможность автоматизировать этот процесс...

 

svl

Мне кажется, что на данном уровне процесс оптимизации является скорее не творческим а рутинным... А решение рутинных задач я обычно стремлюсь переложить на машину, т.к. они мне не очень интересны. Сам механизм перестановки инструкций в коде без изменения его функциональности давно уже реализован в полиморфных вирусах. В данном случае нужен полиморфный движок, который бы не просто менял местоположение команд, а делал бы это по определенным правилам (при этом тесно взаимодействуя с человеком). IMHO, это вполне возможно. И еще: IMHO, для полиморфных движков вирусов существует проблема их размера, в то время как в данном случае (т.к. боевые технологии используются в мирных целях) ее нет, поэтому, я надеюсь, можно реализовать очень мощный движок...



P.S.: Так как я не спец по вирусам, то надеюсь что верно понимаю что такое полиморфизм (хотя могу и ошибаться).

 

> надеюсь что верно понимаю что такое полиморфизм



В данном случае ты описал метаморфизм

 

мне кажется это не так просто:

Ты должен:

1. дизасмить код

2. найти оптимизируемый участок

2.1 проверить нет ли на него переходов

3. заменить на готовый, участок 2

4. Подрезать/удлинить размер



5. еще что нибудь.

 

svl

А я и не говорил что это просто Я только сказал, что IMHO это можно сделать. Но опять же, это только мое имхо, т.к. я этим никогда не занимался и могу что-то не принимать во внимание...

Зачем? Имеется же исходник, ведь оптимизируем же свою прогу...

Ну, еще в этот список можно добавить эмуляцию выполнения кода, т.к. в некоторых случаях нужно будет знать значение тех или иных регистров или "переменных" в определенном месте программы. Хотя эмуляцию можно заменить или продублировать диалогом с человеком (т.е. программа запросит нужную инфу у человека-программиста).

 

Oleg_SK

А WholeProgrammOptimizations и ProfileGuidedOptimizations современных си компиляторов не подходят?

 

semen

Я не знаю, что это за инструменты... Плиз, опиши, что это за инструменты, что они делают и где их можно раздобыть. Поиск в интернете ничего не дал...

 

semen

Я вот подумал, что WholeProgrammOptimizations и ProfileGuidedOptimizations могут относиться к самим компиляторам. Если это так, то скажи: оптимизируют ли они содержимое ассемблерных вставок или оставляют как есть?

 

Oleg_SK



Ассемблерные вставки _никогда_ не оптимизируются.

Наоборот, при определённых условиях, код вокруг них не будет оптимизирован.





semen



Я так понял, что эффекта, как WholeProgrammOptimizations, можно добиться не компилируя .cpp по отдельности + линковка, а включив всё сорцы в один файл )

 

S_T_A_S_

Почти, в случае WPO еще делается "Optimize the use of registers across function boundaries" и например __fastcall может стать совсем не __fastcall и ассемблерная вставка в ней побъется, если был расчет на параметры в ECX и EDX. А PGO так вообще вручную для большого объема кода не сделать.

 

Sched takes specially commented source code and reoutputs the code in an order that can be more optimally executed by an in-order but superscalar or pipelined CPU.

http://www.azillionmonkeys.com/qed/sched.zip



Как я понял из Readme, может оптимизировать асм и Си,

сам не пробовал, ничего сказать не могу.

 

pev

На первый взгляд кажется, что это то, что нужно! Буду смотреть...

 

semen >

IMHO дело в инлийне функций. Оптимизатор "не видит" что аргументы используются и компилирует чушь. Вот болванка где всё это видно.

Код (Text):

1. #pragma comment(linker, "/entry:start")
2. #pragma comment(linker, "/subsystem:windows")
3.  
4. #ifdef  __INTEL_COMPILER
5. #pragma warning(disable:1011)
6. #endif
7.  
8. //__forceinline
9. unsigned __fastcall sum(unsigned a, unsigned b)
10. {
11.     __asm lea  eax, [ecx+edx]
12. }
13.  
14. void start()
15. {
16.     sum(1, 2);
17. }

cl /O2g

Код (Text):

1. 00401000  /> /8D0411        lea     eax, [ecx+edx]
2. 00401003  |. |C3            retn
3.  
4. test.<Mod>|$ |BA 02000000   mov     edx, 2
5. 00401015  |. |B9 01000000   mov     ecx, 1
6. 0040101A  \.^\E9 E1FFFFFF   jmp     test.00401000

icl /O2g

Код (Text):

1. 00401000    8D0411          lea     eax, [ecx+edx]
2. 00401003    C3              retn
3. test.<Mod>  B9 01000000     mov     ecx, 1
4. 00401009    BA 02000000     mov     edx, 2
5. 0040100E    E8 EDFFFFFF     call    test.00401000
6. 00401013    C3              retn

__forceinline активен (оба компилятора)

Код (Text):

1. test.<ModuleE>/$  8D0411        lea     eax, [ecx+edx]
2. 00401003      \.  C3            retn

 

S_T_A_S_

Ну да, из-за инлайна тоже, но и без инлайна у меня WPO в fastcall менял в каких регистрах параметры передаются. Кстати твой пример актуалн не только с WPO(у тебя вообще без WPO), а мой проявляется тока при WPO\PGO.

 

semen

Да, я ключи поэтому и привёл. WPO может форсировать инлайнинг - тогда эта бага оптимизатора и проявляется.

А без WPO такого не будет - если функции в разных модулях, линкер ничего не сможет никуда подставить.

Ты не пытался локализовать проблему? Мне кажется, что PGO всё же ни причём.

Проверить, влияет ли WPO можно заinclude'ив все модули в один (конечно, если это реально).

 

Oleg_SK

Тулза для оптимизации Интеловских программ

сделана самим Интелом - VTune называется.

С ее помощью за час я нашел и оптимизировал большую

Фортрановскую программу. 30% времени ела

программа пересылки данных, это известный

теоретический факт - даже "самая вычислительная"

программа 50-60% времени тратит на пересылку данных.

Кроме того, удалось подтвердить, что программа решения

матрицы ест очень мало времени и нет нужды искать

более оптимальную.

 

S_T_A_S_

Нет, именно потому и сказал, что из-за инлайна тоже - имелось ввиду инлайн который делает WPO, но и без всяких инлайнов WPO меняет регистры в которых передаются аргументы. И я не говорил что это проблема, просто для WPO нельзя во вставках сразу пользовать какой-то регистр, в надежде что это будет аргумент или указатель на фрейм стека, а НЕОБХОДИМО писать mov eax, arg1 и т.д не трогая до этого ebp и esp - тогда все будет работать и даже в случае инлайна. Например, если в твоем примере сделать

Код (Text):

1. __forceinline
2. unsigned __fastcall sum(unsigned a, unsigned b)
3. {
4.     __asm {
5.     mov  ecx, a
6.     mov  edx, b
7.     lea  eax, [ecx+edx]
8.     }
9. }
10.  

то компилятор сгенерит все правильно:

Код (Text):

1. PUBLIC  ?sum@@YIIII@Z                   ; sum
2. ; Function compile flags: /Ogtpy
3. ;   COMDAT ?sum@@YIIII@Z
4. _TEXT   SEGMENT
5. _b$ = -8                        ; size = 4
6. _a$ = -4                        ; size = 4
7. ?sum@@YIIII@Z PROC                  ; sum, COMDAT
8. ; _a$ = ecx
9. ; _b$ = edx
10. ; File d:\_users\1.cpp
11. ; Line 10
12.     sub esp, 8
13.     mov DWORD PTR _b$[esp+8], edx
14.     mov DWORD PTR _a$[esp+8], ecx
15. ; Line 12
16.     mov ecx, DWORD PTR _a$[esp+8]
17. ; Line 13
18.     mov edx, DWORD PTR _b$[esp+8]
19. ; Line 14
20.     lea eax, DWORD PTR [ecx+edx]
21. ; Line 16
22.     add esp, 8
23.     ret 0
24. ?sum@@YIIII@Z ENDP                  ; sum
25. _TEXT   ENDS
26. PUBLIC  ?start@@YAXXZ                   ; start
27. ; Function compile flags: /Ogtpy
28. ;   COMDAT ?start@@YAXXZ
29. _TEXT   SEGMENT
30. ?start@@YAXXZ PROC                  ; start, COMDAT
31. ; Line 20
32.     mov ecx, 1
33.     mov edx, 2
34.     lea eax, DWORD PTR [ecx+edx]
35. ; Line 21
36.     ret 0
37. ?start@@YAXXZ ENDP                  ; start
38.