Экстремальная оптимизация

Крис Касперски

Хакер, номер #091, стр. 091-120-1

Хитрости низкоуровневого программинга для самых маленьких

Ассемблер — это удивительный язык, открывающий дверь в мир больших возможностей и неограниченного самовыражения. Состязания между программистами здесь — обычное дело. Выигрывает тот, у кого нестандартный взгляд, необычный подход. Зачастую, самое «тупое» решение — самое быстрое и правильное.

Путь начинающего ассемблерщика не только долог, но еще и тернист. Повсюду торчат острые шипы, дорогу преграждают разломы, ловушки и капканы. В темной чаще горят злые глаза, доносятся какие-то ухающие звуки и прочие неблагоприятные факторы, нагнетающие мрачную атмосферу и серьезно затрудняющую продвижение вперед.

Большинство учебников затрагивают только MS-DOS, крайне поверхностно описывая практические проблемы программирования под Windows. Поэтому я решил исправить эту проблему и поделитьcя с читателями рецептами, которые известны любому профессионалу, но совершенно неочевидны новичку.

Шотовые функции на блюдечке

Грань между плюсами «мышиного» и «рукописного» кода очень тонка. Отклонение в одну сторону снижает продуктивность программы, в другую — увеличивает (причем зря) время разработки. Короче, не будем разводить демагогию, а рассмотрим фрагмент кода, запускающий процесс на выполнение стандартным способом через win32 API-функцию CreateProcess:

xor eax, eax ; eax := 0

push offset pi ; lpProcessInformation

push offset sis ; lpStartupInfo

push eax ; lpCurrentDirectory

push eax ; lpEnvironment

push eax ; dwCreationFlags

push eax ; bInheritHandles

push eax ; lpThreadAttributes

push eax ; lpProcessAttributes

push offset file_name ; имя исполняемого файла с аргументами

push eax ; lpApplicationName

call ds:[CreateProcess] ; косвенный вызов API-функции через IAT

Ассемблированный код занимает 1Fh байт и еще 54h байта расходуются на структуры PROCESS_INFORMATION и STARTUPINFO плюс длина имени файла. А вот что получится, если воспользоваться морально «устаревшей» функцией WinExec, доставшийся в наследство от 16-разрядной старушки Windows? Вопреки распространенному заблуждению, она реализована одновременно как 16- и 32-разрядная функция, а поэтому перехода в 16-разрядный режим при вызове WinExec из 32-разрядного кода не происходит, а значит, не происходит и падения производительности:

push 00h ; uCmdShow (короче, чем XOR EAX,EAX/PUSH EAX)

push offset file_name ; имя исполняемого файла с аргументами

call ds:[WinExec] ; косвенный вызов API-функции через IAT

Всего три машинные команды, укладывающиеся в 1Eh байт (без учета имени файла) и никаких дополнительных структур! Расплатой за оптимизацию становится невозможность создания отладочных или «замороженных» процессов, не говоря уже про атрибуты безопасности и прочую хрень.

Но это еще не предел оптимизации! Воспользовавшись функцией system из библиотеки MSVCRT.DLL, которая активно используется многими приложениями и практически всегда «болтается» в памяти, мы сократим код до 1Dh байт или даже до 1Ah, если отсрочим восстановление стека, выполнив команду add esp, x в конце функции, выталкивая все аргументы одним махом:

Содержание  Вперед на стр. 091-120-2
ttfb: 2.985954284668 ms