Профайлер?

gprof?!

немного не то. Я могу тупо в проге читать регистры процессора, и мерять производительность. Хочется готовое. Не хочется изобретать велосипед.

Есть ли какая-то бибилиотека, чтобы можно было понатыкать в прогу меток, а она, используя rdtscl потом нарисовала где у меня тормоза? Чтобы выдала среднее время исполнения функции, минимальное, максимальное итд?

Попробуй какой-нибудь сэмплирующий профайлер: vtune интеловский или Google performance tools. Конкретное время исполнения они тебе не покажут, зато узнаешь в какой либе/функции проц у тебя проводит больше всего времени.

> Есть ли какая-то бибилиотека, чтобы можно было понатыкать в прогу меток, а она, используя rdtscl потом нарисовала где у меня тормоза? Чтобы выдала среднее время исполнения функции, минимальное, максимальное итд?

Я бы предложил sb-sprof, но ты ведь не на Коммон Лиспе пишешь ;)

Можно попробовать свежий systemtap. Он умеет трейсить юзерспейс через utrace и строить разнообразную статистику.

Мне не просто «в какой функции сколько времени» а еще нужно знать в какой функции с какими данными. Если я к примеру хочу узнать прозводительность memcopy, то мне нужна статистика по вызову этой функции с мегабайтом данным, килобайтом, и гигабайтом. А толку мне от профайлера, который скажет сколько времени у меня она в среднем работает?

У меня чистый C, правда с нитями, и опцией разрешающий SSE, 64 бита.

А, ептыть, припоминаю тебя: теперь в каждом посте будут появляться все новые и новые детали и условия, что делает бесполезным любой разговор о любой задаче.

> Мне не просто «в какой функции сколько времени» а еще нужно знать в какой функции с какими данными. Если я к примеру хочу узнать прозводительность memcopy, то мне нужна статистика по вызову этой функции с мегабайтом данным, килобайтом, и гигабайтом. А толку мне от профайлера, который скажет сколько времени у меня она в среднем работает?

Любой профайлер тебе эти данные испоганит, т.к. здорово ломает времянку программы. Замерять memcpy нужно ручками: http://www.linux.org.ru/jump-message.jsp?msgid=3305745&cid=3309986

> У меня чистый C, правда с нитями, и опцией разрешающий SSE, 64 бита.

Точности до такта профайлером не добьёшься. Если интересно примерное время выполнения, то системтапом вот так можно: http://13-49.livejournal.com/77006.html

А какой-то библиотеке на основе информации из rdtsc нету? Чтобы просто натыкать туда и все.

Хотя уже можно пробовать. Хотя муторно.

Та мне не точности. мне что-то вроде

TIME_1_START
printf(....
x=x+y;
TIME_2_START
b=sin(t);
TIME_2_END
TIME_1_END
и чтобы на выходе я получил таблицу где было бы написано сколько работало максимум, минимум и в среднем. TIME_1, TIME_2 итд. Через rdtsc можно написать, но ИМХО должно быть готовое.

В произвольное место в тексте программы, откомпилированной с оптимизацией, воткнуться, практически, невозможно. Если хватит уровня функций, то системтап (с оговоркой) может помочь. Я сам статистические возможности stap'а не пользовал, но, если память не изменяет, в его библиотеке такое есть.

Оговорка: т.к. системтап работает из кернельспейса, то на каждой точке перехвата происходит переключение контекста. Это минимум 1-1.5 тысячи тактов только на само переключение, плюс нужно накинуть тактов на обработку данных самим системтапом. Мелкие вещи, соответственно, уже не померяешь. И если твой алгоритм оперирует с большим кол-вом данных, то постоянный сброс кеша при переключениях может здорово испоганить времянку.

Нашел TAU профайлер. Вроде оно.

> А какой-то библиотеке на основе информации из rdtsc нету? Чтобы просто натыкать туда и все.

valgrind + cachegrind вот ещё есть, но это тоже не панацея...

>Подскажите, чем можно воспользоваться, хочется в программе наставить меток, и замерять время исполнения кода между ними. Что готовое есть?

Ъ-олдскул: перед входом и после входа в код кидать что-то в порт ввода-вывода и мерять частоту осциллографом.

Нашел TAU профайлер. Вроде оно.

Во! Совсем забыл! В новых ядрах (.30+) появился perf_events (раньше называлось perf_counters). Используя эту штуку можно понять почему код медленно работает:

* (in-package :perfcounters)

#<PACKAGE "PERFCOUNTERS">
* (time+ (loop for i from 0 below 10 collect i))

Performance monitor:
 18,449 CPU cycles consumed
 8,238 instructions executed
 132 cache hits
 10 cache misses
 0 branch instructions
 0 branch missess
 54,868,226,022 bus cycles
 7,851 cpu clocks
 7,626 task clocks
 0 page faults
 0 context switchs
 0 cpu migrations
 0 minor fault
 0 major faults

(18449 8238 132 10 0 0 54868226022 7851 7626 0 0 0 0 0)

Простите за Лисп, в Си можно то же самое сделать. Здесь кроме кол-ва инструкций видно, сколько раз попали или промахнулись мимо кеша, сколько было ветвлений, сколько из них было предсказано правильно и т.п.

> перед входом и после входа в код кидать что-то в порт ввода-вывода и мерять частоту осциллографом.

Вот когда я был embedded программистом, я так и делал.

Блин, оно хочет прогонять исходники через свой компилятор. Ни у кого идей нет, что есть более высокоуровневое для доступа к rdtsc ?

Блин, оно хочет прогонять исходники через свой компилятор. Ни у кого идей нет, что есть более высокоуровневое для доступа к rdtsc ?

ИМХО на любой многозадачной ОС с помощью rdtsc ты получишь не более точные данные, чем при помощи обычных нормальных профайлеров. Если точность тебя не сильно интересует, то rdtsc замени на clock_gettime (опять же - ИМХО).

Меня полностью устраивает rdtsc. Но хочется более высокоуровневое. Точность интересует. Кое где хочется проверить сколько времени вычисляется логарифм к примеру.

Так в чём проблема? Напиши сам. А то ты хочешь заведомо узкозаточенное решение причём сразу готовое, но такое в природе встречается редко =).

Меня полностью устраивает rdtsc.

...

Точность интересует.

Взаимоисключающие параграфы. Затык на дисковой подсистеме в соседнем процессе и у тебя в коде

a = b; будет полсекунды выполняться =).

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

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

Там 10 строчек-то самому писать...

А записать в файл, а красиво нарисовать.... Я пока не могу понять, каждый сам для себя даже обращения к rdtsc пишет, через ассемблерные вставки?

Да забудь ты уже про rdtsc и прочитай man 2 clock_gettime (тебе надо CLOCK_MONOTONIC). Оно хотя бы время не в тактах выдаёт, а сразу в секундах + наносекундах.

Я уже не говорю про кроссплатформенность =).

> Я уже не говорю про кроссплатформенность =).

Оно в ядро лезет, одиночный замер покажет муру.

Оно в ядро лезет, одиночный замер покажет муру.

А rdtsc разве не муру покажет? Думаю точность замеров получится примерно одинаковой.

> А записать в файл,

Плюс три строки.

а красиво нарисовать....

Пиши в файл в формате, который gnuplot или octave понимает.

Я пока не могу понять, каждый сам для себя даже обращения к rdtsc пишет, через ассемблерные вставки?

Кнопки «сделать зашибись» пока не придумали.

> А rdtsc разве не муру покажет? Думаю точность замеров получится примерно одинаковой.

Нет. Если между двумя rdtsc не произошло переключения контекста, то будет очень точно.

Нет. Если между двумя rdtsc не произошло переключения контекста, то будет очень точно.

Это ведь можно гарантировать, только если поток/процесс работает с приоритетом реального времени. Разве в этом случае clock_gettime не даст ту же точность? Просто замеренное время будет больше на небольшую фиксированную величину - затраты на вызов. Или я где-то сильно ошибаюсь?

> Это ведь можно гарантировать, только если поток/процесс работает с приоритетом реального времени. Разве в этом случае clock_gettime не даст ту же точность? Просто замеренное время будет больше на небольшую фиксированную величину - затраты на вызов. Или я где-то сильно ошибаюсь?

Разница примерно как между а) сходить в туалет дома и б) съездить в центр города и воспользоваться туалетом на вокзале. В первом случае - это одна минута, во втором - время на сборы, на подход к остановке, ожиданию транспорта, время хода транспорта до центра, обстановка с пробками, вероятность сан.обработки туалета и т.д.

rdtsc - однотактовая машинная команда, не влияющая абсолютно ни на что, sys_clock_gettime - системный вызов со всеми сопутствующими прямыми и косвенными расходами.

По поводу того, что затраты будут больше - это я согласен. Но зато кроссплатформенно и без ассемблерных вставок =).

rdtsc - однотактовая машинная команда, не влияющая абсолютно ни на что, sys_clock_gettime - системный вызов со всеми сопутствующими прямыми и косвенными расходами.

Какой смысл говорить про такты на процессоре с конвеером?

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

Ты физику учил, да? Когда ты что-то пытаешся измерить в системе, то ты вносишь в систему изменения. Эти изменения могут значительно изменить всю наблюдаемую картину.

Для измерения скорости участков кода следствия будут такими:

хочешь высокой точности (порядка 200-300 тактов) - жертвуй количеством результатов и наглядностью

Хочешь наглядность - жертвуй точностью.

ЗЫ: Скачай себе VTune и не парь мозги.

ЗЗЫ: Еще есть AMD CodeAnalyst

> ЗЫ: Скачай себе VTune и не парь мозги.

На торрентс.ру, только для винды.

> Еще есть AMD CodeAnalyst

У меня для Интел.

Интел выкладывает свои продукты только на торрентс.ру ? О_о

Марш бегом на официальный сайт, там под некомерческую разработку в Линухе дают скачать

Тебе наклейка нужна или ехать?

Мне ехать, но хотелось бы оставить в проге контроль времени исполнения отдельных частей, чтобы в случае чего (выход за пределы кеша или еще чего), я об этом сразу узнал.

На 30 дней дают. И сам файл в 500 мегабайт. :(

Да не триалку качай!

Тебе в раздел Free Non-commercial Downloads

> Тебе в раздел Free Non-commercial Downloads

Теже 509 мегабайт.

Я заметил)

oprofile же.

ессно без втыкания меток - между метками может и context switch приключиться или начаться ожидание чтения с диска.

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