К. Касперски - Техника оптимизации программ, Эффективное использование памяти (1127752), страница 20
Текст из файла (страница 20)
Итак, выбираем инте- рактивную оптимизацию и нажимаем кнопку Хех1, расположенную чуть правее раскрываюшегося списка. Содержимое экрана тут же преобразится (рис. 1.10) и на левой панели будет показан исходный ассемблерный код, а на правой — оптимизируемый код. В нижнем правом углу экрана по ходу оптимизации будут отображаться так называемые "азвцп1рг(оп" (буквально — допушения), за разрешением кото- рых оптимизатор будет обращаться к программисту. На рисунке в этом окне выведено следующее допушение: Ассер1 ОИзе! ОИзе12 Аззвпгр1!оп Оезсг!р1!оп Ч Ох55 Ох72 !пз1гысйопз гпау гз!егепсз йз загпз гпегпогу (Инструкции со смешениями Ох55 и Ох72 обращаются к одной и той же об- ласти памяти). Смотрим„что за инструкции расположены по таким смеше- ниям.
Ага: ызз тое Ы72 еое еьр, рвовп рта геереотвь! риокс Рта !еер+Огсю, есх Несмотря на кажушиеся различия в операндах, на самом деле они адресуют одну и ту же переменную, т. к. между ними расположены две машинные команды ривн, уменьшающие значение регистра ЕВР на 8. Таким образом, это предположение верно и мы подтверждаем его нажатием кнопки Арр!у, находяшейся в верхней левой части экрана. Теперь обратим внимание на инструкции, залитые красным цветом (на рисунке они с наиболее темной заливкой) и отмеченные красным огоньком светофора слева. Это отвратительно спланированные инструкции, обложенные "штрафными" тактами процессора. Давайте шелкнем по самому нижнему "светофору" и посмотрим, как профилировщик УТипе перегруппирует наши команды.
Ну вот, совсем другое дело! Теперь все инструкции залиты пастельным желтым цветом, что означает: никаких конфликтов и штрафных тактов нет. Что в оптимизированном коде изменилось? Ну, во-первых, теперь команды рсзн (заталкиваюшие регистры в стек) отделены от команды, модифицируюшей регистр указатель вершины стека, что Профилировка программ о7 уничтожает паразитную зависимость по данным (действительно, нельзя затал- кивать свежие данные в стек пока не известно положение его вершины). Рис.
1.10. Использование Ассемблерного Тренера для оптимизации планирования машинных команд Во-вторых, арифметические команды теперь равномерно перемешаны с командами записи/чтения регистров, поскольку вычислительное устройство (АЛУ вЂ” арифметико-логическое устройство) у процессоров Репгшгп всего одно, то зта мера практически удваивает производительность. В-третьих, процессоры Ре11бцт содержат только один полноценный х86- декодер и потому заявленная скорость декодирования три инструкции за такт достигается только при строго определенном следовании инструкцией.
Инструкции, декодируемые только полноценным х8б-декодером, следует размешать в начале каждого триплета, заполняя "хвост" триплета команлами, которые "по зубам" остальным двум декодерам. Как легко убедиться, компилятор МБ НС генерирует весьма неоптимальный с точки зрения Репбшп-процессора код и профилировшик НТвпе перетасовывает его команды по-своему (листинг 1.24). ець еер, Юаь ог есх, -1 ееЬ еер, Оаь реев еЬх вв Глава ! рпаь еЬр еЬр, ОХОКО РтК 1еар+01ВЛ1 рпаь еЬх еЬр еЬр, РИОКО Рта ~еар~010ц рпаь еа1 рпаь рпаь тс е хсг еах, еах еб1, еЬр есх, -1 еах, еах еЬх, еЬх ебх, -1 рнаь рпаь тсе ебг еЬх, еЬх ебх, -1 ебг, еЬр хсг хсг хсг тсе герье асааЬ пег есх бес есх герпе асааЬ ОЯОКО РТК !еар+02ОП), ебх есх пег тот ОЯОКО РТК ~еаР+02ОЬ1, тсе Оясвь РтК !еар+010Ь1, бес есх Около Ртк [еар+01001, есх есх тсг Нажимаем еще раз кнопку 1(ех1 и переходим к анализу следующего блока инструкций.
Теперь профилировщик ЪТцпе устраняет зависимость по дан- ным, разделяя команды чтения и сложения регистра ЕЯ! командой увеличе- ние регистра ЕАХ: еа1, Отсвп Ртв ~еах+еьр! еаг, РЖОКО РТК ~еах+еьр1 тпт ебх, еаг гпс еах 1пс абб ебх, еа1 стр еак, еск стгр еах, есх Действуя таким образом, мы продолжаем до тех пор, пока весь код целиком не будет оптимизирован. И тут возникает новая проблема. Как это ни прискорбно, но профилировщик ггТцпе не позволяет поместить оптимизированный код в исполняемый файл, видимо, полагая, что программистассемблершик без труда перенаберет его с клавиатуры и вручную.
Но мы-то с вами не ассемблершики! (В смысле: среди нас с вами есть и не ассемблершики). И лотом — как прикажете "перебивать" код? Не резать же двоичный файл "в живую"? Конечно нет! Давайте поступим так (не самый лучший вариант, конечно, но ничего более умного мне в голову пока не пришло). Переместив курсор в панель оптимизированного кода в меню Я!е, выберем пункт РПп1. В окне Р!е!о Бе!есйоп (Выбор полей) снимем флажки со всего, кроме 1аЬе!в (Метки) и 1пв(гпс1!опв (Инструкции) и зададим печать в файл или буфер обмена. Тем временем подготовим ассемблерный листинг нашей программы, задав в командной строке компилятора ключ ггк (в других компиляторах этот ключ, разумеется, может быть и иным).
В результате мы станем обладателями файла рвтег!.авпк который даже можно откомпилировать (т1 гс гсс11 Профилировка программ ьаье1 1ПЗЬпоопзепз деп рзеб евр, 88Ь деп разо+36 ~1:86> ев1, сибво Рта (еаз+еьр1 деп разо+28 вое Во-первых, после меток не стоит знак двоеточия, во-вторых, в метках встре- чается запрещенный знак "плюс", в-третьих, условные переходы содержат лишний адрес, заключенный в скобки на конце.
Словом нам предстоит много ручной работы, после которой "вычищенный" фрагмент программы будет выглядеть так, как в листинге 1.26. 1 Ьет 1пвезповзопв деп реев; евр, 88Ь деп раисе 36 +гедд+ езз, ЬЯОРЬ РТР (еак+еЬр1 зв депрзеба 28 Остается заключить его в следующую "обвязку" и оттранслировать ассембле- ром ТАЯМ или МАЯМ вЂ” это уже как вам больше нравится (листинг 1.27). .386 рвеб.а*и), СЛИНКОВатЬ (1апх Г88881818И:СОВ888 рвеб.оЬ3 Ьтве,щв) И запустить. Но что за черт! Мы получаем скорость всего 65 миллионов паролей в секунду против 83 миллионов, которые получаются при оптимизации обычным путем.
Оказывается, коварный МК ЧС просто не вставляет директивы выравнивания в ассемблерный текст! Это затрудняет оценку производительности качества оптимизации кода профилировщиком агТипе. Ну, да ладно, возьмем за основу данные 65 миллионов и посмотрим, насколько УТипе сможет улучшить этот результат. Открываем файл, созданный профилировщиком, и еще одна проблема! Его синтаксис совершенно не совместим с синтаксисом популярных трансляторов ассемблера (листинг 1.25)! 90 Глава 1 оеп раиб РОВЬ1С Оеогурс:РВОС РгьпГЕЧНЕАВ иа11ос:ЫЕАВ ехтевн ехтвн ехтвн ОАТА Беомент иу асг1пд Овтп Еноз Ов 'овс тех: ггу го бесгург; "'а" , сан, сон техт Веоиевт реп Раиб РВОС НЕАВ // ход функции реп рана реп ранб ЕНОР техт еноз ЕНО А в самой программе рзгуг1.с функцию д Р б объявить как внешнюю. Это можно сделать например так, как показано в листинге 1.28.
ехгегп гпг реп р*нб(сьаг *сгургеббага, сьаг *рано, гпе иах тсег, гпс ца1гбСЮ у Теперь можно собирать наш проект воедино — листинг 1.29. аб /с /сост реп раиб.ааи с1 /Ох ранб.с /11пн оеп ранб.оьс Прогон оптимизированной программы показывает, что она вьшает 78 миллионое паролей в секунду, что на 20% больше, чем было до оптимизации. Что ж! Профилировшик г/Типе весьма не слабо оптимизирует код! Тем не менее, полученный результат все же не дотягивает до скорости, достигнутой на предыдушем шаге. Конечно, камень преткновения не в профилировщике, а в компиляторе, но разве от этого нам легче? Впрочем, на оптимизации собственных ассемблерных программ эта проблема никак не отражается.
Профилировка программ Итоги и прогнозы 91 Рис. 1.11. Хронология оптимизации парольного перебортцика Теперь самое время подвести итоги. Если откинуть первый неудачный вариант программы с постоянным вызовом функции ртьятг, можно сказать, что мы увеличили скорость оптимизируемой программы с полутора до восьмидесяти четырех миллионов паролей в секунду, т. е. без малого на два порядка! И у нас есть все основания этим гордиться! Пускай мы далеко от теоретического предела и до исчерпания резерва производительности (вот скажем, можно перебирать несколько паролей одновременно, используя векторные ММХ-команды), профилировка приложений, несомненно, лучшее средство избежать неоправданного снижения производительности! Любопытно, но каждый шаг оптимизации приводил к экспоненциальному росту производительности (рис.
!.! !). Конечно, экспоненциальный рост наблюдается далеко не во всех случаях (можно сказать, что тут нам просто повезло), но, тем не менее, обшая тенденция профилировки такова, что самые крупные "камни преткновения" по обыкновению находятся "на глубине" и разглядеть их, не "окунувшись в воду" (в смысле в дебри кода), в обшем-то, невозможно. Глава ! В этой главе мы рассмотрели лишь самые базовые средства профилировщика ЪТцпе (да и то мельком), но его возможности этим отнюдь не исчерпаются! Можно сказать, что это целый мир, содержащий, помимо всего прочего, собственный язык программирования и даже имеющий собственный интерфейс АР(, позволяющий вызывать функции УТипе из своих программ (читай: "клепать" к профилировщику собственные плагины). Но, как бы то ни было, первый шаг в изучении профилировщика УТипе уже сделан и в дальнейшем вы постепенно сможете осваивать его и самостоятельно.
А напоследок рискну дать вам один совет. Пользоваться контекстной помощью ЪТипе крайне неудобно и множество разделов при этом так и остаются неохваченными. Поэтому лучше воспользоваться любым (зе!рдекомпилятором и конвертировать Н! Р-файл в КТР, который затем можно открыть с помощью того же редактора %огс! и распечатать. Или, во всяком случае, — читать с экрана, ибо помощь занимает свыше трех тысяч страниц — бумаги не напасешься! Глава 2 Оперативная память Память определяет быстродействие.
Фон-Негсяан Самый медленный верблюд определяет скорость каравана. Арабское народное Время работы программы определяется ее самой медленной частью. Закон Амдааа Введение Миллиарды битовых ячеек, упакованных в крошечную керамическую пластинку (рис. 2.1), свободно умещающуюся на ладони...
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
