К. Касперски - Техника оптимизации программ, Эффективное использование памяти (1127752), страница 6
Текст из файла (страница 6)
В силу того, что разработчики имеют прямой доступ к документации процессоров!пге1, у них больше возможностей принимать во внимание особенности процессоров. Об оптимальности кода или каком-либо принципиальном превосходстве иад другими компиляторами говорить ие стоит. — Рецензент. Да, семейству процессоров х86 присущи многие проблемы и ограничения. Но это ничуть не оправдывает программистов, пишущих "уродливыи" код и палец о палец не ударяющих, чтобы хоть как-то его улучшить. А "язык" процессоров х86, между прочим, очень интересен.
На сегодняшний день они имеют едва ли не самую сложную систему команд, дающую системным программистам безграничные возможности для самовыражения. Прикладные программисты даже не догадываются, сколько красок мира у них украли компиляторы! Глава 1 Профилировка программ Про4илировкой здесь и на протяжении всей книги мы будем называть измерение производительности как всей программы в целом, так и отдельных ее фрагментов, с целью нахождения "горячих" точек /Ног ороп), — тех участков программы, на выполнение которых расходуется наибольшее количество времени. Согласно правилу "1О/90", десять процентов кода "съедают" девяносто процентов производительности системы (равно как и десять процентов людей выпивают девяносто процентов всего пива). Если время, потраченное на выполнение каждой машинной инструкции, изобразить графически в порядке возрастания их линейных адресов, на полученной диаграмме мы обнаружим несколько высоченных пиков, горделиво возвышающихся над практически пустой равниной, усеянной множеством низеньких холмиков (пример показан далее на рис.
1.6 равд. 'Практический сеанс профилировки с УТипе в десяти шагах') Вот эти самые пики — "горячие" точки и есть. Почему "температура" различных участков программы столь неодинакова? Причина в том, что подавляющее большинство вычислительных алгоритмов так или иначе сводится к циклам, — т. е. многократным повторениям одного фрагмента кода, причем зачастую циклы обрабатываются не последовательно, а образуют более или менее глубокие иерархии, организованные по типу "матрешки". В результате, львиную долю всего времени выполнения программа проводит в циклах с наибольшим уровнем вложения, и именно их оптимизация дает наилучший прирост производительности! Громоздкие и тормозные, но редко вызываемые функции оптимизировать нет никакой нужды, — это практически не увеличит быстродействия приложения (ну разве что только в том случае, если они совсем уж будут "криво" написаны).
Когда же алгоритм программы прост, а ее исходный текст свободно умещается в сотню-другую строк, то "горячие" точки нетрудно обнаружить и визуальным просмотром листинга. Но с увеличением объема кода это становится все сложнее и сложнее. В программе, состоящей из тысяч сложно взаимодействующих друг с другом функций (часть из которых это функции Глава У внешних библиотек и АР! — Арр11сагюп Ргоягатшп(пя 1пгег(асе, интерфейс прикладного программирования — операционной системы), далеко не так очевидно: какая же именно из них в наибольшей степени ответственна за низкую производительность приложения.
Естественный выход — прибегнуть к помощи специализированных программных средств. Профилировщик (так же называемый "профайлером") — основной инструмент оптимизатора программ. Оптимизация "в слепую" редко дает хороший результат. Помните пословицу "Самый медленный верблюд определяет скорость каравана"? Программный код ведет себя полностью аналогичным образом, и производительность приложения определяется самым узким его участком.
Бывает, что виновницей оказывается одна-единственная машинная инструкция (например, инструкция деления, многократно выполняющаяся в глубоко вложенном цикле). Программист, затратив воистину титанические усилия на улучшение остального кода, окажется премного удивлен, что производительность приложения едва ли возросла процентов на десять-пятнадцать. Правило номер один: ликвидация ие самых "горячих" точек программы, практически ие увеличивает ее быстродействия.
Действительно, сколько не подгоняй второго сзади верблюда — от этого караван быстрее идти не будет (случай, когда предпоследний верблюд тормозит последнего — это уже тема другого разговора, требующего глубоких знаний техники профилировки, а потому и не рассматриваемая в настоящей книге).
Цели и задачи профилировки Основная цель профилировки — исследовать характер аоведемвя Прилажеиия во всех его тачках. Под "точкой" в зависимости от степени детализации может подразумеваться как отдельная машинная команда, так целая конструкция языка высокого уровня (например: функция, цикл или одна- единственная строка исходного текста). Большинство современных профилировщиков поддерживают следующий набор базовых операций: С) определение общего времени исполнения каждой точки программы (гота! [зро1з] 11щ(пя); П определение удельного времени исполнения каждой точки программы ([зрогз] г)пшел); (".1 определение причины и/или источника конфликтов и пенальти (репа!!у 1п(огшагюп); (.'1 определение количества вызовов той или иной точки программы ([зрогз] соил!); 0 определение степени покрытия программы ([зрогз] сочег(пя).
Профилироака программ Общее время исполнения Сведения о времени, которое приложение тратит на выполнение каждой точки программы, позволяют выявить его наиболее "горячие" участки. Правда, здесь необходимо сделать одно уточнение. Непосредственный замер покажет, что, по крайней мере, 99,99% всего времени выполнения профилируемая программа проводит внутри функции ва, но ведь очевидно, что "ГОряЧЕй" яВЛяЕтСя ОтНЮдЬ НЕ СаМа ваап, а ВЫЗЫВаЕМЫЕ ЕЮ фуНКцИИ! ЧтОбЫ у программистов не было недоумения, профилировщики обычно вычитают время, потраченное на выполнение дочерних функций, из общего времени выполнения каждой функции программы. Рассмотрим, например, результат профилировки некоторого приложения профилировщиком ргой1е,ехе, входящим в комплект поставки компилятора М(сгобой Ч18ца1 С++.
н1« Б'опо4СЫ14) топо тае 4 Т1ве 4 Соево Гппо«1пп 10000 бо рвеб )рвеб х.оЬЗ) 10000 Сатоп1апеоне )рвеб х.оЬ3) Ь0000 Сьео«СНС )рв б х.оЬ3) 1 чеп рвхб )рвеб х.оЬ7) ваап )рвеб х.оЬ3) 1 рптпо бов )рвеб х.оЬ3) 360,982 98,9 5,700 1,6 350, 192 95, 9 5,700 1, б 5,090 1,4 2,841 0,8 1,226 0,3 0,098 0,0 10,790 3,0 363, 824 99, б 365, 148 100, 0 0,098 0,0 В СрЕдНЕй КОЛОНКЕ (Г о+СЬ11б т ве) ПрИВОдИтея ПОЛНОЕ ВрЕМя ИСПОЛНЕНИЯ КажДОй фуНКЦИИ, ЛЬВИНаЯ ДОЛЯ КОТОРОГО ПРИНаДЛЕжИт фуНКЦИИ вате (НУ, этого и следовало ожидать), за ней с минимальным отрывом следует 9 р ) со своими 99,6%, далее идет бо рв 1 — 98,9% и, сильно отставаЯ от нее, где-то там на отшибе плетется сь «сне, оттягивая на себя всего лишь 3,0%.
А функцией са1 1апеснс, с ее робким показателем 1,6%, на первый взгляд можно и вовсе пренебречь! Итак, судя по всему, мы имеем три "ГОРЯЧИХ" ТОЧКИ: ва'и, 9еп р б И бо р б (РИС. 1.1). Впрочем, функцию ап можно откинуть сразу. Она, понятное дело, ни в чем не "виновата". Остаются функции 9 р б и бо р б. Если бы это были абсолютно независимые функции, то "горячих" точек было бы и впрямь две, но в нашем случае это не так.
И, если из полного времени выполнения фуНКНИИ чеп рвеб ВЫЧЕСТЬ ВрЕМя ВЫПОЛНЕНИЯ ЕЕ дОЧЕрНЕй фуНКцИИ бо рвеб, у "матери" останется всего лишь 0,7%. Да! Меньше процента времени выполнения! го Глава 1 Рис. 1.1. Диаграмма, иллюстрирующая общее время выполнения каждой из функций. На первый взгляд, здесь три "горячих" точки, но на самом деле это не так 100,00% „СаьявсйС ~'','к!',:Фф ~01ь!я„ Са1яйаИСЯС 00,00% 80,00% 10,00% 60,0096 50,00% % 40 00% 30,00% 20,00% 10,00% 0,00% вяРвяв Рио. 1.2. Диаграмма, иллюстрирующая чистое время работы каждой из функций (т.
е. с вычетом времени дочерних функций). Как видно, в программе есть одна, но чрезвычайно "горячая" точка ,"Г' *'..", В вправит ;) ";; )йф~),'ф~," '; ", 'а '1~,"~;:)стаЯ * иа1л Профипировка программ 11ое С1оск 11ска зоохсе Сеорехаоосе еа11е((++реев(р])>'а')( * "**** *************** *»> раеа(р) = '('8 ******** ** * у=у( у«8; * 188 г х — = зз К = (( «8; 109 ыо з Х += Ох59( *** 111 г 11г р+е( Вот теперь совсем другое дело — сразу видно, что целесообразно оптимизировать, а что и без того уже "вылизано". "1орячие" точки главным образом сосредоточены вокруг конструкции р о(р), — она очень медленно выполняется. Почему? Исходный текст не дает непосредственного ответа на поставленный вопрос и потому совсем не ясно: что конкретно следует сделать для понижения "температуры" "горячих" точек. Приходится спускаться на уровень "голых" машинных команд (благо профилировщик УТцпе это позволяет).
Вот, например, во что компилятор превратил безобидный на вид оператор присвоения р е((р) = ( (листинг 1.3). Обратимся к крайней левой колонке (листинг 1.1) таблицы профилировщика (Госсе ттее), чтобы подтвердить наши предположения. Действительно, в программе присутствует всего лишь одна "горячая" точка — оо р еа, и только ее оптимизация способна существенно увеличить быстродействие приложения (рис. 1.2).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
