А чем вы профайлите C?

А чем вы профайлите C?

Кастомером.

Нет многонитевости? Требует CommonLisp? Да ты упоролся.

Дай угадаю, это монте-карло + ptrace (или что там в BSD)? Забавная идея, надо украсть.

Спасибо, что спас от хождения по ссылкам. Уж ты-то наверняка корифей профилирования и твои идеи уже включены во все канпиляторы!

Уж ты-то наверняка корифей профилирования

А то.

канпиляторы!

А еще я грамотный,

На common lisp программа, генерирующая отчеты. Не на C же её писать.

На common lisp программа, генерирующая отчеты

Это достаточно прямо написано по ссылке.

Не на C же её писать.

Есть масса более распространенных языков.

И таки да, отсутствие многонитевости ставит крест.

И таки да, отсутствие многонитевости ставит крест.

Блин, это очень даже печально. Вот какой-то Дональд Кнут говорил, что она ему не понадобилась. Мне пока тоже, так что я не стал заморачиваться

А то.

Меня иногда тоже так торкает.

В такие моменты я профилирую. Каждый день я хожу по коду и внимательно собераю все говно которое вижу. На два полных дня анализа целый день уходит. Зато, когда после тяжёлого дня я прихожу домой, иду в ванну, включаю ПК…ммм и сваливаю свое сокровище. И дрочу, представляя, что меня поглотил единый организм профайлера. Мне вообще кажется, что подпрограммы, умеют думать. А вчера, мне преснился чудный сон, как будто я нырнул в море, и оно прератилось в неоптимизированные подпрограммы,баги, логические бомбы, ошибки, все для профилирования, даже небо, даже Аллах!.

Наркоман!

отсутствие многонитевости ставит крест.

Блин, это очень даже печально.

Не то слово. Только хотел попробовать, как сразу облом.

Вот какой-то Дональд Кнут говорил, что она ему не понадобилась

Кнут святой и пишет TeX, а я простой быдлокодер и немного пишу цифродробилку.

Не то слово. Только хотел попробовать, как сразу облом.

Кстати, а ты можешь посоветовать, как обрабатывать сигнал от таймера (SIGPROF) в многопоточной проге? Вот на stack overflow вычитал, что на pid можно определить только один обработчик сигнала. Т.е. как я понял только один тред и будет его ловить. А вот можно ли из него остановить остальные потоки разом и посмотреть их контекст?

Не то слово. Только хотел попробовать, как сразу облом.

Надо было скрывать правду ;) Может ты бы ещё и доволен остался.

Только хотел попробовать, как сразу облом.

А лисп у тебя есть, значит? )

Кстати, а ты можешь посоветовать, как обрабатывать сигнал от таймера (SIGPROF) в многопоточной проге?

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

А лисп у тебя есть, значит? )

У меня - нет, но он есть в Debian. Пожалуй, я смог бы себя заставить набрать apt-get install нужные пакеты.

А еще я грамотный,

Да не, ты просто Царя не слушаешь, с его конпиляторами и чоткими пацанами на раёне.

ТС, про Valgrind слышал? BSD RIP.

но он есть в Debian

А профайлер даже не для ляликса, такие дела. Тупой анонимус сверху подсказывает, что у вас есть valgrind. Хотя можно легко портировать

А профайлер даже не для ляликса, такие дела

Да, по ссылке написано. Но там же написано «easy to add support».

_Полагаю_, что в этом нашем Линупсе каждая нить может установить свой обработчик сигнала

Как это сделать? Я джва года ждал этой фичи!

В простых случаях ставлю свой засекатель времены выполнения, в сложных - valgrind.

_Полагаю_, что в этом нашем Линупсе каждая нить может установить свой обработчик сигнала

Как это сделать?

signal(7) говорит, что мое предположение неверно и напрямую это сделать нельзя. Видимо, я перепутал с LinuxThreads.

Я джва года ждал этой фичи!

Просто для протокола: не следует мешать водку с пивом ^W^W^Wнити и сигналы.

signal(7) говорит, что мое предположение неверно и напрямую это сделать нельзя.

Все мои надежды что послали лесом POSIX разбиты.

Видимо, я перепутал с LinuxThreads.

Раньше было лучше!

Просто для протокола: не следует мешать водку с пивом ^W^W^Wнити и сигналы.

Иногда очень надо.

Просто для протокола: не следует мешать водку с пивом ^W^W^Wнити и сигналы.

Иногда очень надо.

Если ты не можешь сделать на имеющихся средствах - значит, не надо.

Если ты не можешь сделать на имеющихся средствах - значит, не надо.

Эти имеющиеся средства иногда приводят к удивительно кривым решениям: к примеру, в позиксе нет wait() с мультиплексированием. Можно SIGCHLD, который нельзя с нитями и еще кое с чем, или по нити на дочерний процесс. Это не круто.

Просто для протокола: не следует мешать водку с пивом ^W^W^Wнити и сигналы.

Эх, а я считал тебя специалистом!

а я считал тебя специалистом!

Не ты первый, не ты последний, так что не расстраивайся.

позиксе

Ты немец что ли?

А сигмаск и signalfd не пытался заюзать никогда? Я вот всё хочу, только задачи не попадается.

Эти имеющиеся средства иногда приводят к удивительно кривым решениям: к примеру, в позиксе нет wait() с мультиплексированием

Если тебе нужно ждать несколько некооперативных процессов, у тебя уже кривое решение.

The name POSIX was suggested by Richard Stallman. It is expected to be pronounced pahz-icks, as in positive, not poh-six, or other variations. The pronunciation has been published in an attempt to promulgate a standardized way of referring to a standard operating system interface.

А в чем проблема? Коллеги так прозносят.

А сигмаск и signalfd не пытался заюзать никогда? Я вот всё хочу, только задачи не попадается.

Для этой задачи у меня таргет - OS X, и BSD'шный kevent проблему решает.

Если тебе нужно ждать несколько некооперативных процессов, у тебя уже кривое решение.

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

А в чем кривизна заключается?

В том, что они не сообщают «работу закончил, сейчас вызову exit».

подождать по порядку не выйдет.

Просто для протокола - я этого и не предлагал.

В том, что они не сообщают «работу закончил, сейчас вызову exit».

Они сообщают через fd, но там кривые 3rdparty библиотеки, которые собственно и делают всю грязную работу. Они могут сегфолтнутся и тогда отряд не заметит потери бойца.

Просто для протокола - я этого и не предлагал.

Это была моя первая, наивная реализация.

Они сообщают через fd, но там кривые 3rdparty библиотеки

Но виноват POSIX %)

Они могут сегфолтнутся и тогда отряд не заметит потери бойца.

Как это не заметит? На fd будет EOF, улавливаемый poll. После чего вызываешь waitpid на pid, соответствующем fd, и узнаешь судьбу потомка.

Но виноват POSIX %)

Ну раз уж в системе не «все - файл», как обещали, то мультиплексирование можно не только для файлов предусмотреть.

Как это не заметит? На fd будет EOF, улавливаемый poll. После чего вызываешь waitpid на pid, соответствующем fd, и узнаешь судьбу потомка.

Спасибо.

А ок, это мне тогда нужно к логопеду.

В линуксе есть prof - просто суперский инструмент, прост как тапок, но при желании можно и поподробнее навернуть профайлинг. Соболезную пользователю bsd.

valgrind может работать в статистическом режиме, а не в режиме эмуляции? просто любопытно, ибо valgrind хорошо и если он есть под bsd - хорошо

https://dl.dropboxusercontent.com/u/31471800/p2p/Screenshot - 14.12.2014 - 22...

Оно?

Не могу понять, ЕСЛИ НЕ ОШИБАЮСЬ статистическая профилировка это такая, при которой нет оверхеда, просто профилировщик смотрит раз в N миллисекунд где находилась программа, ну а далее по call-стэку становится ясно где чаще всего застали выполнение программы. Так и замедления нету, и более менее достоверные результаты. Хотя valgrind может считать даже единичные вызовы и возможно больше подходит для отладки вычислительного алгоритма...

Итак, в твоем случае программа под профилировкой насколько медленнее работает?

Не вижу разницы на глаз при отрисовке большого количества геометрических фигур N раз в секунду только средствами процессора.

А как вызвать valgrind в таком режиме? Просто и мне будет полезно знать, а заодно и ТС узнает чем заменить убогий gprof...

А я через гуй QtCreator'а вызываю, через сосноль не заморачиваюсь. В гуе все искаропки.

Вынужден признать, что Intel Amplifier VTune - очень хорош.