Разработчики файловой системы PohmelFS (http://www.ioremap.net/projects/pohmelfs) и распределённого хранилища Elliptics (http://www.ioremap.net/projects/elliptics/) представили (http://www.ioremap.net/node/972/)
инструментарий React (https://github.com/reverbrain/react) (Real-time Call Tree), предназначенный для отслеживания времени выполнения различных частей кода в проектах на языках C и C++. React предоставляет специальную библиотеку, позволяющую добавлять специальные метки в код и генерировать дерево выполнения блоков, выводимое в формате JSON и учитывающее время работы программы в каждом из блоков.
Для анализа накопленных данных поставляется скрипт для визуализации информации в форме графиков. Применение React уже позволило значительно поднять эффективность организации работы с кэшем в проектах Elliptics и Eblob. При разработке библиотеки основное внимание уделено минимизации накладных расходов в процессе измерения и простоте использования. Код поставляется под лицензией LGPLv2.1.<center><a href="http://reverbrain.com/wp-content/uploads/2014/05/trace.jpg&q... src="http://www.opennet.me/opennews/pics_base/0_1400138065.jpg" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
URL: http://www.ioremap.net/node/972/
Новость: http://www.opennet.me/opennews/art.shtml?num=39780
А разве valgrind этого не умеет?
Именно время никогда особо не интересовало, но скорее всего он должен это уметь.
> А разве valgrind этого не умеет?
> Именно время никогда особо не интересовало, но скорее всего он должен это
> уметь.callgrind умеет, но немного не то.
Если чуть внимательнее новость читать, то генерация идёт на основе _меток_ добавленных. В валгринде я меток не помню.
Ну да, т.е. валгринд ещё удобней:)
Там есть опция --show у callgrind_annotate
Могучая вещь - комплекс неполноценности.
Как послали парня с его kevent-ом в LKML, так он с тех пор горы сворачивает.
Профайлер вот изобрел. Ну всё ж не программу для управления коллекциями фотографий, и то хорошо.
Могучая вещь, конечно, но профайлер никто не изобретал. Читать внимательно: " You can think of it as a real-time callgrind with no overhead and user-defined call branches."
Ах, ну да, простите, Callgrind же у нас менеджер коллеций фотографий.
> Могучая вещь, конечно, но профайлер никто не изобретал. Читать внимательно: " You
> can think of it as a real-time callgrind with no overhead
> and user-defined call branches."Просто комментаторы как обычно говорят о том, чем не пользовались.
Это точно. Они ничего кроме кислых щей и лаптей и не видали.
Ну может еще один глобальный счетчик вложенности, преаллоцированный буфер, указатель текущей в нем позиции, snprintf в местах меток да перловый скрипт из 15 строк.
А тут такие технологии двадцать второго века, дефайны вместо snprintf-а, масштаб инноваций-то сложно так вот сразу осознать.
И тем не менее... Вполне бывает нужно. Приведите пример АНАЛОГИЧНОГО инструмента, который лучше и я, вполне возможно, буду его пользовать. А пока посмотрю это или и дальше буду своим аналогичным костылем пользоваться.
Если серьезно, то основной плюс React-а (и самодельных костыликов) в том что (почти все) традиционные профайлеры рассматривают программу как набор функций - название Callgrind нам об этом ненавязчиво напоминает.
В современных же реалиях значение имеют скорее отдельные statements.А совсем в идеале надо печатать трассу где рядом с каждым statement-ом будет стрелочка туда куда ожидал branch prediction в процессоре (хотя, кажется, этого даже интел не умеет рассказывать), с большим красным восклицательным знаком если следующая инструкция не оправдала его надежд, ну или хотя бы там где кэши L1-3 пришлось сбрасывать.
Use VTune, Luke.
> Use VTune, Luke.Не всегда нужно ездить за хлебом на самолете.
Да и VTune далеко не без недостатков.
Cachegrind выглядит относительно неплохо, но http://valgrind.org/docs/manual/cg-manual.html (пункты 5.8.2 и 5.8.3)
http://www.agner.org/optimize/#testpЭлементарно встраивается в любой код. Позволяет снимать не только время выполнения куска кода, но и такие (если, конечно, проц поддерживает) счетчики, как количество сделанных бренчей, количество неправильно предсказанных их же, количество выполненных микроопераций и т.д. и т.п.
Сбрасывай все в файл и визуализируй сколько хочешь, чем хочешь и как хочешь.
p.s. Я хуею, дорогая редакция, неужели у опеннета нету новостей, что приходится какой-то детский самокатик в новости выкатывать??
Что-то мне подсказывает что со счетчиками perf справляется куда лучше.
> http://www.agner.org/optimize/#testp
> Элементарно встраивается в любой код. Позволяет снимать не только время выполнения куска
> кода, но и такие (если, конечно, проц поддерживает) счетчики, как количество
> сделанных бренчей, количество неправильно предсказанных их же, количество выполненных
> микроопераций и т.д. и т.п.
> Сбрасывай все в файл и визуализируй сколько хочешь, чем хочешь и как
> хочешь.
> p.s. Я хуею, дорогая редакция, неужели у опеннета нету новостей, что приходится
> какой-то детский самокатик в новости выкатывать??Отличная утилита! Я не сомневаюсь, что она великолепно справляется с задачей, которая перед ней ставится, а именно:
"Can measure clock cycles and performance monitor counters such as cache misses, branch mispredictions, resource stalls etc. in a small piece of code in C, C++ or assembly"React предназначен для постоения Trace'а в большой системе, в которой мы считаем не количество операций увеличивания счётчика, etc, а количество сетевых запросов, запросов работы с диском, тяжелых вычислительных функций.
Ок. Был невнимателен.
> Могучая вещь - комплекс неполноценности.Действительно, даже имя известного человека в качестве ника заставляет использовать...
Посоветуйте имя какого-нибудь неизвестного.
вот подходящий ник для тебя: "пустоголовое трепло"
> вот подходящий ник для тебя: "пустоголовое трепло"у школьников подгорают анусы. упоительное зрелище.
На том стоим.
На анусах? ;)
Запилите к этой штуке https://github.com/brendangregg/FlameGraph кто-нибудь, кстати.
И посылатель в statsd в отдельном треде, с регулируемым интервалом посылания накопленного.
> И посылатель в statsd в отдельном треде, с регулируемым интервалом посылания накопленного.Это можно сделать уже сейчас.
Для этого необходимо создать свой aggregator, который будет посылать call_tree в statsd/"ваш любимый коллектор" при вызове мегода aggregate, и передать этот aggregator при создании контекста react-a в функцию react_activate.
После этого можно вызывать react_submit_progress для сабмита текущего состояние call_tree.
Что-то я не помню чтоб там в коде была реализация UDP-протокола statsd.
> Что-то я не помню чтоб там в коде была реализация UDP-протокола statsd.React это утилита для сбора статистики выполнения программы. Способы, которыми она сбрасывает статистику на диск, находятся вне её компетенции и могут быть любыми.
Если вы хотите использовать в качестве коллектора statsd, вам необходимо получить
во время исполнения программы call_tree, которое сгенерирует react, а затем воспользоваться
одним из многих клиентов для statsd, например https://github.com/talebook/statsd-client-cpp
что-бы отправить собранную react'ом статистику туда.
Pohmel? Да это название почище Pidora будет.
Это традиционные россиянские приколы.
GIN и VODKA - индексы в PostgreSQL, например.
Превед танкистам! :)
Оно уж давно аносировано http://www.opennet.me/opennews/art.shtml?num=15561
А я все жду когда в QtCreator вставят профайлер наподобие того, что есть в кодеблоке )
Было бы header-only - еще можно было бы о чем-то говорить.
Привет! Изначально React действительно был header-only, но потом появилась необходимость поюзать его в C. Недавно я придумал, как сделать его header-only в С++, что-бы это осталось совместимым с С-шной версиеи. В ближайшее время запилю. Если интересно - спрашивайте.
Зачем? Необходимость С-интерфейса очевидна и понятна с первой секунды для таких тулзов.
Какую функциональность добавляет С++ интерфейс?
Как раз с точностью до наоборот.
Какую функциональность добавляет С++ интерфейс?
> Как раз с точностью до наоборот.Нормальный синтаксис, отсутствие необходимости таскать void*, возможность простого расширения, постоения своих аггрегаторов для любых систем сбора trace'ов.
На C нельзя реализовать очень удобную для мониторинга концепцию guard'а
Не надо реализовывать 5 одинаковых с точки зрения реализации функций
add_stat_int
add_stat_bool
add_stat_string
...Главный аргумент: удобней пользоваться
Я работал с разными профилировщиками... но именно такой инструмент мне был нужен!
Да-да! Я тоже не знаю, как раньше жил без реакта!
Похмель русскоговорящие разрабатывали?
> Похмель русскоговорящие разрабатывали?А что, есть сомнения?
