С.В. Герасимов, И.В. Машечкин, М.И. Петровский и др. - Инструментальные средства разработки ПО в ОС UNIX, страница 8
Описание файла
PDF-файл из архива "С.В. Герасимов, И.В. Машечкин, М.И. Петровский и др. - Инструментальные средства разработки ПО в ОС UNIX", который расположен в категории "". Всё это находится в предмете "операционные системы" из 3 семестр, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 8 страницы из PDF
.. #include <stdlib.h>........... .. #include <time.h>........... ............. .. int main()81110040000 00 {........... ..int i;........... ..int a[1000];20000010000 00double avg = 0.0;........... ..40000041100 00srand(time(NULL));3,00411 2,00100100 1,001 12 00for(i = 0; i <1000; i++)3,00000 1,00000 2,000453500 00a[i] = rand();........... ..3,00400 2,00100100 1,001 10 00for(i = 0; i <1000; i++)8,00000 4,00000 2,0000000 00avg += a[i];...........
..40021110000 00avg /= 1000;........... ..10000000000 00return 0;60040000000 00 }-------------------------------------------------------------------------------Ir I1mr ILmr Dr D1mr DLmr Dw D1mw DLmw Bc Bcm Bi Bim-------------------------------------------------------------------------------604 900 10109 51 00 percentage of events annotatedcg_annotate может быть использован для построчногоаннотирования и машинных команд. Для этого программа,написанная, например, на Си, должна быть предварительнотранслирована в ассемблер с помощью опции –S, после чегоскомпилирована в режиме отладки (–g). Результат аннотирования:-- Auto-annotated source: /usr/home/test/valgrind/cachegrind.s-------------------------------------------------------------------------------Ir I1mr ILmrDr D1mr DLmrDw D1mw DLmwBc Bcm Bi Bim......111......100......100......001......000......000......001......00044......000......000......000......000......000.file "cachegrind.c".text.p2align 4,,15.globl main.type main,@functionmain:leal 4(%esp), %ecxandl$-16, %esppushl-4(%ecx)1000001100000010000011000001100000010000001000001100000110000011000001100000110000011000000.......1,00000 1,0000001,00000000 1,0001,00000000 1,0004020(%ebp,%ebx,4)1,00000 1,000000.......1,00111 1,0010001,00100000010000011000000.......1,00000 1,0000001,00000 1,0000004020(%ebp,%eax,4), %eax1,00000000 1,0001,00000 1,0000001,0000000001,00000 1,0000001,0000000001,00000000 1,0001,00000 1,000000.......1,00100 1,00100020(%ebp)1,00100000010010001001110100000010000011000000100000010010001001000100100010000001001000...............rodata...................................(GNU) 4.2.1 20070719 [FreeBSD]"0000000100000.00450000000100000.00350000000000000.0000000000000000.0000000000000000.0000000000000000.000pushl%ebpmovl%esp, %ebppushl%ebxpushl%ecxsubl$4032,%espfldzfstpl-16(%ebp)movl$0, (%esp)calltimemovl%eax,(%esp)callsrandmovl $0, -20(%ebp)jmp.L2.L3:movl -20(%ebp),%ebxcall randmovl %eax,-0.0000.0000..000 1,0010000..00000.01200.000.0000.000.0000.00addl.L2:cmpljlemovljmp.L6:movlmovl0000000.00000000.00000000.00000000.00000000.00000000.0pushl%eaxfildl(%esp)leal 4(%esp), %espfldl-16(%ebp)faddp%st, %st(1)fstpl-16(%ebp)addl $1, -20(%ebp).L5:cmpl$999, -000000000000..0 1,0010000000000000000000000....1000000000000..000000000000..000000000000..jle.L6fldl-16(%ebp)fldl.LC1fdivrp %st, %st(1)fstpl-16(%ebp)movl$0, %eaxaddl$4032, %esppopl%ecxpopl%ebxpopl%ebpleal -4(%ecx), %espret.size main, .-main.section..........................align 8.LC1:.long.long.ident.....$1, -20(%ebp)$999,-20(%ebp).L3$0, -20(%ebp).L5-20(%ebp),%eax-01083129856"GCC:-------------------------------------------------------------------------------Ir I1mr ILmr Dr D1mr DLmr Dw D1mw DLmw Bc Bcm Bi Bim-------------------------------------------------------------------------------604 900 10109 51 00 percentage of events annotated45С точки зрения информативности, целесообразно запускатьcachegrind на программе, скомпилированной с отладочнойинформацией (опция –g), однако тонкую оптимизациюпроизводительности имеет смысл проводить на программе,скомпилированной в рабочей конфигурации с включеннойоптимизацией кода.
Чтобы преодолеть это противоречие существуетутилиты cg_merge и cg_diff, позволяющие объединять либонаходить различия между двумя версиями файла вывода cachegrind.Итоговый файл может быть передан в cg_annotate для анализа.CallgrindПри разработке высоконагруженных приложений либореализации алгоритмов обработки больших массивов данных частовозникает необходимость в поиске функциональности, критическивлияющей на производительность программы. Узкие места могутбыть найдены с помощью замеров времени в коде программы.Другим способом является использование профилировщика вызововфункций. Инструмент callgrind строит дерево вызовов функцийпрограммы.
Для каждой функции рассчитывается суммарнаястоимость (англ., inclusive cost) и собственная стоимость (англ.,exclusive cost), выраженные в числе машинных инструкций. Еслифункция f вызывает функцию g, то число инструкций g войдут всуммарную стоимость f. Собственную стоимость f составятинструкции функции без учета инструкций по обращению к g.Таким образом, суммарная стоимость функции main составляет100% стоимости программы.
Собственная стоимость функции – эточисло вызванных инструкций данной функции, за исключениеминструкций по обращению к другим функциям.Командная строка для запуска callgrind:valgrind –tool=callgrind имя-программы [аргументы]Инструментсоздаетвыходнойфайлсименемcallgrind.out.<PID процесса>, который может быть обработанутилитой callgrind_annotate с помощью командной строки:callgrind_annotate [опции] callgrind.out.<pid>46callgrind_annotate во многом аналочичен cg_annotate. Списокфункций упорядочен по собственной стоимости. Некоторые опцииcallgrind_annotate:--inclusive=<yes|no> [по умолчанию: no]yes - вместо сортировки по собственной стоимостииспользуется сортировка по суммарной стоимости.--tree=<none|caller|calling|both> [по умолчанию: none]Способ отображения дерева вызовов: caller - по каждойфункции выводится список функций, вызвавших ее; calling –отображаются вызванные функции, both – комбинациярежимов caller и calling.
Ниже приведен фрагмент дерева,построенного в режиме calling, для следующего примерапрограммы:#include <string.h>int strcmp2(char *p, char *q){while(*p && *p == *q){p++;q++;}return *p - *q;}int strcmp2_d(char *p, char *q){int i = 0;while(i < strlen(p) && i < strlen(q) && p[i] == q[i])i++;return p[i] - q[i];}int main(){char * p = "qwertyasdfghzxcvbn";char * q = "qwertyasdfghzxcvbN";strcmp2(p, q);strcmp2_d(p, q);return 0;}47Фрагмент вывода:2,704 * callgrind.c:main[/usr/home/test/valgrind/a.out]228 >callgrind.c:strcmp2 (1x)[/usr/home/test/valgrind/a.out]2,452 >callgrind.c:strcmp2_d (1x)[/usr/home/test/valgrind/a.out]2,452 * callgrind.c:strcmp2_d[/usr/home/test/valgrind/a.out]980 >???:strlen (35x) [/lib/libc.so.7]1,074 >???:0x00001658 (1x) [/libexec/ld-elf.so.1]Для наглядного отображения дерева вызовов рекомендуетсяиспользовать средство графической визуализации KCacheGrind:Callgrind также включает в себя функции по симуляции кэш ипредсказанию переходов, аналогичные cachegrind.Автоматическое тестирование в CUnitНа сегодняшний день любое реально используемоепрограммное обеспечение находится в состоянии непрерывнойдоработки – разработчиками выпускаются все новые и новыеверсии, содержащие исправления ошибок, реализацию новыхтребований заказчика, изменения, обусловленные обновлениямисопутствующего ПО: выходом новых версий операционных системи библиотек.
В такой ситуации «ручное» тестирование каждойновой модификации не является хорошей идей в виду большого48объема трудозатрат и рутинности процесса. На помощь приходитавтоматическое тестирование, суть которого заключается виспользовании программных средств для выполнения тестов иконтроля результатов их выполнения, что помогает сократить времятестирования и упростить его процесс. Разновидностямиавтоматического тестирования являются:Системное тестирование (англ., system testing) – тестированиесистемы как «черного ящика» (без знаний деталей реализации)с помощью сценариев, близких к сценариям использованиясистемы в реальной работе.Модульное тестирование (англ., unit testing) – тестированиет.н.методом«белогоящика»,подразумевающеготестированиевнутреннихфункцийиметодов,непосредственно реализующих систему.
Цель модульноготестирования – показать, что отдельные части программысами по себе функционируют без ошибок. Модульноетестирование реализуется с помощью создания наборатестов, описывающих сценарии вызова функций исравнивающих фактические результаты работы с ожидаемымипри помощи набора проверок (англ., assert), входящих в составсистемы модульного тестирования. Тесты являются обычнымифункциями/методами,написанныминаязыкепрограммирования высокого уровня, и включаются в состависходных текстов программы. Как правило, систематестированиятакжевключаетв себя подсистемуавтоматического запуска тестов (в т.ч.
с графическимпользовательским интерфейсом). Для проверки корректностипрограммы после внесения очередных модификацийнеобходимо лишь активировать запуск тестов.Широкую популярность сегодня приобрел подход разработкачерез тестирование (англ., test-driven development), в основекоторого лежит идея реализации/доработки функциональностиминимальными частями, причем до реализации новой функциидолжны быть написаны модульные тесты на нее. Написание тестовдо реализации позволяет заранее продумать программныеинтерфейсы и сценарии использования новой функциональности.49Автоматическоетестированиеиразработкатестирование обладают следующими преимуществами:черезИнкрементально пополняемый набор тестов снижает рисквнесения ошибки при модификации ПО.Автоматическая проверка тестов позволяет уменьшить издержкипо сравнению с рутинным «ручным» тестированием.Наличие набора автоматических тестов положительно влияет напсихологическое состояние программистов, вносящих изменениев ПО.Опережениереализациинаписаниемтестовпозволяетспроектироватьпрограммныеинтерфейсыновойфункциональности на раннем этапе цикла разработки.Использование модульных тестов неизбежно приводит кнеобходимости разумной декомпозиции программного кода иуменьшению связности между его частями и, как результат, ккоду более высокого качества.Для начала использования модульного тестирования, вообщеговоря, не требуется какое-либо специализированное средство,достаточно описать проверочные сценарии в виде функций на языкепрограммирования и реализовать простейший метод, вызывающийсценарии и отображающий результаты их выполнения.
Дляреализации модульного тестирования на Си программисту можетпригодиться макрос стандартной библиотеки assert(cond), аварийнозавершающий программу при невыполнении условия cond.Одной из распространенных систем модульного тестированияпрограмм,написанныхнаязыкеСи,являетсяCUnit(http://cunit.sourceforge.net). В CUnit тест является функцией языкаСи, не имеющей параметров и возвращающего значения. Логическикаждый тест является листом следующей иерархии:Реестр тестов (англ., test registry)o Набор тестов (англ., test suite) Тест (англ., test)Для тестов, входящих в набор, могут быть заданы функцияустановки (англ., setup) и функция очистки (англ., teardown)контекста.