| 1.1, A.Stahl (ok), 11:29, 15/05/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 А разве valgrind этого не умеет?
Именно время никогда особо не интересовало, но скорее всего он должен это уметь.
| | |
| |
| 2.4, Nuzhny (?), 11:41, 15/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А разве valgrind этого не умеет?
> Именно время никогда особо не интересовало, но скорее всего он должен это
> уметь.
callgrind умеет, но немного не то.
| | |
| 2.6, ф (?), 11:53, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если чуть внимательнее новость читать, то генерация идёт на основе _меток_ добавленных. В валгринде я меток не помню.
| | |
|
| 1.2, rob pike (?), 11:29, 15/05/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Могучая вещь - комплекс неполноценности.
Как послали парня с его kevent-ом в LKML, так он с тех пор горы сворачивает.
Профайлер вот изобрел. Ну всё ж не программу для управления коллекциями фотографий, и то хорошо.
| | |
| |
| 2.3, Nuzhny (?), 11:40, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Могучая вещь, конечно, но профайлер никто не изобретал. Читать внимательно: " You can think of it as a real-time callgrind with no overhead and user-defined call branches."
| | |
| |
| 3.5, rob pike (?), 11:50, 15/05/2014 [^] [^^] [^^^] [ответить]
| –5 +/– |
Ах, ну да, простите, Callgrind же у нас менеджер коллеций фотографий.
| | |
| 3.8, ф (?), 11:55, 15/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Могучая вещь, конечно, но профайлер никто не изобретал. Читать внимательно: " You
> can think of it as a real-time callgrind with no overhead
> and user-defined call branches."
Просто комментаторы как обычно говорят о том, чем не пользовались.
| | |
| |
| 4.11, rob pike (?), 12:15, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Это точно. Они ничего кроме кислых щей и лаптей и не видали.
Ну может еще один глобальный счетчик вложенности, преаллоцированный буфер, указатель текущей в нем позиции, snprintf в местах меток да перловый скрипт из 15 строк.
А тут такие технологии двадцать второго века, дефайны вместо snprintf-а, масштаб инноваций-то сложно так вот сразу осознать.
| | |
| |
| 5.17, _yurkis_ (ok), 13:05, 15/05/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 И тем не менее... Вполне бывает нужно. Приведите пример АНАЛОГИЧНОГО инструмента, который лучше и я, вполне возможно, буду его пользовать. А пока посмотрю это или и дальше буду своим аналогичным костылем пользоваться.
| | |
| |
| 6.18, rob pike (?), 13:18, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если серьезно, то основной плюс React-а (и самодельных костыликов) в том что (почти все) традиционные профайлеры рассматривают программу как набор функций - название Callgrind нам об этом ненавязчиво напоминает.
В современных же реалиях значение имеют скорее отдельные statements.
А совсем в идеале надо печатать трассу где рядом с каждым statement-ом будет стрелочка туда куда ожидал branch prediction в процессоре (хотя, кажется, этого даже интел не умеет рассказывать), с большим красным восклицательным знаком если следующая инструкция не оправдала его надежд, ну или хотя бы там где кэши L1-3 пришлось сбрасывать.
| | |
| 6.32, Uri (??), 17:22, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– | |
http://www.agner.org/optimize/#testp
Элементарно встраивается в любой код. Позволяет снимать не только время выполнения куска кода, но и такие (если, конечно, проц поддерживает) счетчики, как количество сделанных бренчей, количество неправильно предсказанных их же, количество выполненных микроопераций и т.д. и т.п.
Сбрасывай все в файл и визуализируй сколько хочешь, чем хочешь и как хочешь.
p.s. Я хуею, дорогая редакция, неужели у опеннета нету новостей, что приходится какой-то детский самокатик в новости выкатывать??
| | |
| |
| 7.47, acid (?), 21:26, 15/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > 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, а количество сетевых запросов, запросов работы с диском, тяжелых вычислительных функций.
| | |
|
|
|
|
|
| 2.14, Аноним (-), 12:31, 15/05/2014 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> Могучая вещь - комплекс неполноценности.
Действительно, даже имя известного человека в качестве ника заставляет использовать...
| | |
| |
| |
| |
| 5.30, arisu (ok), 16:51, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > вот подходящий ник для тебя: "пустоголовое трепло"
у школьников подгорают анусы. упоительное зрелище.
| | |
|
|
|
|
| |
| 2.13, rob pike (?), 12:29, 15/05/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
И посылатель в statsd в отдельном треде, с регулируемым интервалом посылания накопленного.
| | |
| |
| 3.27, acid (?), 16:16, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> И посылатель в statsd в отдельном треде, с регулируемым интервалом посылания накопленного.
Это можно сделать уже сейчас.
Для этого необходимо создать свой aggregator, который будет посылать call_tree в statsd/"ваш любимый коллектор" при вызове мегода aggregate, и передать этот aggregator при создании контекста react-a в функцию react_activate.
После этого можно вызывать react_submit_progress для сабмита текущего состояние call_tree.
| | |
| |
| |
| 5.48, acid (?), 21:35, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Что-то я не помню чтоб там в коде была реализация UDP-протокола statsd.
React это утилита для сбора статистики выполнения программы. Способы, которыми она сбрасывает статистику на диск, находятся вне её компетенции и могут быть любыми.
Если вы хотите использовать в качестве коллектора statsd, вам необходимо получить
во время исполнения программы call_tree, которое сгенерирует react, а затем воспользоваться
одним из многих клиентов для statsd, например https://github.com/talebook/statsd-client-cpp
что-бы отправить собранную react'ом статистику туда.
| | |
|
|
|
|
| |
| 2.10, rob pike (?), 12:00, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Это традиционные россиянские приколы.
GIN и VODKA - индексы в PostgreSQL, например.
| | |
|
| 1.12, trdm (ok), 12:26, 15/05/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 А я все жду когда в QtCreator вставят профайлер наподобие того, что есть в кодеблоке )
| | |
| |
| 2.24, acid (?), 16:08, 15/05/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Привет! Изначально React действительно был header-only, но потом появилась необходимость поюзать его в C. Недавно я придумал, как сделать его header-only в С++, что-бы это осталось совместимым с С-шной версиеи. В ближайшее время запилю. Если интересно - спрашивайте.
| | |
| |
| 3.36, rob pike (?), 18:25, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– |
Зачем? Необходимость С-интерфейса очевидна и понятна с первой секунды для таких тулзов.
Какую функциональность добавляет С++ интерфейс?
| | |
| |
| |
| 5.49, acid (?), 21:39, 15/05/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Как раз с точностью до наоборот.
Нормальный синтаксис, отсутствие необходимости таскать void*, возможность простого расширения, постоения своих аггрегаторов для любых систем сбора trace'ов.
На C нельзя реализовать очень удобную для мониторинга концепцию guard'а
Не надо реализовывать 5 одинаковых с точки зрения реализации функций
add_stat_int
add_stat_bool
add_stat_string
...
Главный аргумент: удобней пользоваться
| | |
|
|
|
|
|
