Компания Google представила (http://google-opensource.blogspot.ru/2014/01/introducing-ben...) новую открытую библиотеку для организации тестирования производительности функций в программах на языке С++, используя подход, похожий на unit-тесты. Библиотека позволяет организовать тестирование производительности отдельных блоков кода, варьируя входные данные и число итераций. На основании собранных данных формируется наглядный отчёт. Код библиотеки открыт (https://github.com/google/benchmark) под лицензией Apache.
<center><a href="http://1.bp.blogspot.com/-wk7hsdYodo8/UtS75FZag6I/AAAAAAAAAk... src="http://www.opennet.me/opennews/pics_base/0_1389814501.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
URL: http://google-opensource.blogspot.ru/2014/01/introducing-ben...
Новость: http://www.opennet.me/opennews/art.shtml?num=38866
Народу халяву надо: LD_PRELOAD=/usr/lib/libbenchmark.so ./helloworld;
На выходе - графики, статистика и варианты исправления (см. w3c validator).
А тут ещо код менять... Пффф... придумают тоже :)
Типа Intel system studio ?
Valgrind вроде что-то умеет в этом духе.
Я, правда, его лишь как анализатор утечек использую, он он многое умеет.
да Паша про такое наверняка знает.
полезный набор утилит. только в режиме эмуляции, раз в 10 медленнее получается. единственный недостаток.
> Valgrind вроде что-то умеет в этом духе.Умеет. Правда капризный, зараза - на абы как скомпиленой программе можно и пообломаться.
Используй халяву: perf (linux-tools) - будет просто как ты написал, или valgrind - будет точно как аптеке но медленно.
Вывод: годная библиотека, я вероятно ей и буду пользоваться, я люблю такие штуки.
Да-да-да, самые феншуйные - это ядрёные...
CONFIG_KERNEL_DEBUG, mount -t debugfs none /sys/kernel/debug
и фпирёд рекурсивно, с пивом и бубном...
# -*- coding: utf-8 -*-
import random
print random.choice([u'Уух, тормозит', u'Докупи памяти, голодранец!', u'Графики строить? А кооператив тебе не построить?'])пока, конечно, программа несовершенна, но ещё пара версий, и будет самая вещь!
> пока, конечно, программа несовершенна, но ещё пара версий, и будет самая вещь!Хм... вся суть питоновских программистов одной короткой программой :).
К сожалению толку от подобных утилит мало.
для студентов, разве что. в целом, гораздо полезнее книжки чтать, это да. профилировщики всякие использовать, стараться тупости в программах не делать.
но я посмотрю завтра всё равно, а вдруг что интересное найду. мало ли.
Ну давайте , покажите как вы будете L1/L2 cache miss ( для примера ) без этих утилит оптимизировать .
gprof и включение мозгов - вполне себе. или благородный Дон решил меня испугать кэшем первого уровня?
если уж совсем без всяких утилит - в книге К. Касперски поверхностно затронут вопрос, до глав с разбором AMD Codeanalyst. стиль изложения, правда, мне не очень нравится.
Как то не совсем gprof для этого , по моему .
Включение мозгов - это всегда хорошо .
vtune/cachegrind + мозги как то более логично для этой задачи , не находите ?
valgrind не на всех компах себе могу позволить. да и на старом компе, или на ARM косяки быстрее бросаются в глаза :) а gprof - везде можно применить. вполне себе нормально. можно включать те, или другие участки программы для профилировки. ну и примерное представление нужно иметь о попаданиях в кэш, структуры данных, соответственно, подгонять под "проблематику" процессора. конечно, gprof грубоватый анструмент, но вполне себе приемлемый: считает количество вызовов и количество тактов.
> valgrind не на всех компах себе могу позволить. да и на
> старом компе, или на ARM косяки быстрее бросаются в глаза :)
> а gprof - везде можно применить. вполне себе нормально. можно включать
> те, или другие участки программы для профилировки. ну и примерное представление
> нужно иметь о попаданиях в кэш, структуры данных, соответственно, подгонять под
> "проблематику" процессора. конечно, gprof грубоватый анструмент, но вполне себе приемлемый:
> считает количество вызовов и количество тактов.https://gist.github.com/hellerbarde/2843375
Так сказать масштаб вашего заблуждение по поводу gprof ( на х64/86 архитектуре ) ;)
многочисленными итерацими оно и выясняется. кто-то утверждал другое? :) подобные штучки хорошо видны в числодробилках, а если мультипликация небольшой матрицы разок где-то засветится нечаянно в программе, то овчинка выделки не стоит, конечно.
> gprof и включение мозгов - вполне себе. или благородный Дон решил меня
> испугать кэшем первого уровня?
> если уж совсем без всяких утилит - в книге К. Касперски поверхностно
> затронут вопрос, до глав с разбором AMD Codeanalyst. стиль изложения, правда,
> мне не очень нравится.http://www.akkadia.org/drepper/cpumemory.pdf
Вполне себе ничего .
> Касперски поверхностноЭтим всё сказано.
для ознакомления - вполне нормально. еще вторая книжка планировалась - продолжение.
>gprof и включение мозговнесовместимы. Пользоваться этой штукой можно только до тех пор, пока не узнаешь, что она на самом деле измеряет.