Профилировщики (выборки) все еще лгут в наши дни?

Что касается gprof, да, это все еще так. Это сделано специально для того, чтобы минимизировать накладные расходы на профилирование. Из актуальной документации:

Некоторые цифры в графе вызовов являются оценочными, например, значения времени дочерних элементов и все значения времени в строках вызывающей программы и подпрограммы.

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

Сделано предположение, что среднее время, затрачиваемое на каждый вызов любой функции foo, не коррелирует с тем, кто вызывал foo. Если foo использовал всего 5 секунд, и 2/5 вызовов foo исходили от a, то foo добавляет 2 секунды к времени дочерних элементов a, по предположению.

Что касается KCacheGrind, то с момента написания статьи мало что изменилось. Вы можете проверить журнал изменений и убедиться, что последняя версия была опубликована 5 апреля. , 2013 г., который включает несвязанные изменения. Вы также можете обратиться к комментариям Йозефа Вайдендорфера под статьей (Джозеф — автор KCacheGrind ).

Нет, многие современные профилировщики выборки не имеют проблемы, описанной в отношении gprof.

На самом деле, даже когда это было написано, конкретная проблема на самом деле была скорее причудой того, как gprof использует сочетание инструментария и выборки, а затем пытается реконструировать гипотетический график вызовов на основе ограниченного числа вызывающих/вызываемых абонентов. информацию и объединить ее с дискретизированной информацией о времени.

Современные профилировщики выборки, такие как perf, VTune и различные профилировщики для языков, которые не компилируются в собственный код, могут захватывать полный стек вызовов с каждой выборкой, что обеспечивает точное время в отношении этой проблемы. В качестве альтернативы вы можете выполнить выборку без сбора стеков вызовов (что значительно снижает стоимость выборки), а затем представить информацию без какой-либо информации о вызывающем/вызываемом абоненте, которая все равно будет точной.

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

Конечно, профилировщики могут лгать по-разному. Например, получение результатов, точных на уровне инструкций, является очень сложной проблемой, учитывая современные ЦП с сотнями инструкций, выполняемых одновременно, возможно, по многим функциям, и сложные модели производительности, где инструкции могут иметь совершенно другую стоимость в контексте по сравнению с к их номинальным значениям задержки и пропускной способности. Даже эти сложные проблемы можно решить с помощью «аппаратной помощи», например, на последних чипах x86 с поддержка PEBS и более поздние связанные функции, которые помогут вам точно определить инструкцию менее предвзятым образом.

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

Какова твоя цель? А) выяснить, как сделать программу максимально быстрой? Или для Б) измерения времени, затрачиваемого различными функциями, в надежде, что это приведет к А? (Подсказка — это не так.) Вот подробный список проблем.

Для иллюстрации: вы могли бы, например, вызвать маленькую невинно выглядящую маленькую функцию где-нибудь, которая случайно вызывает девять ярдов системного кода, включая чтение .dll для извлечения строкового ресурса, чтобы интернационализировать его. Это может занимать 50% времени настенных часов и, следовательно, находиться в стеке 50% времени настенных часов. Покажет ли это вам «CPU-profiler»? Нет, потому что практически все эти 50% приходится на ввод-вывод. Вам нужно много образцов стека, чтобы точно знать с точностью до 3 знаков после запятой, сколько времени это занимает? Конечно, нет. Если бы у вас было только 10 образцов, это было бы на 5 из них, плюс-минус. Как только вы узнаете, что подростковая рутина — это большая проблема, значит ли это, что вам не повезло, потому что ее написал кто-то другой? Что, если бы вы знали, что это за строка, которую он ищет? Действительно ли он должен быть интернационализирован настолько, что вы готовы заплатить за это вдвое медленнее? Вы понимаете, насколько бесполезны измерения, когда ваша настоящая проблема состоит в том, чтобы качественно понять, что требует времени?

Я мог бы продолжать и продолжать подобные примеры...