Лучшая стратегия для профилирования использования памяти моего кода (с открытым исходным кодом) и стороннего кода (с закрытым исходным кодом) - PullRequest
7 голосов
/ 31 мая 2011

Вскоре мне будет поручено создать надлежащий профиль памяти для кода, написанного на C / C ++ и использующего CUDA для использования преимуществ обработки графическим процессором.

Сначала я хотел бы создать макросыи перегрузки операторов, которые позволили бы мне отслеживать вызовы malloc, free, delete и новые вызовы в моем исходном коде.Я мог бы просто включить другой заголовок и использовать макросы __FILE__ and __LINE__ для печати вызовов памяти в файл журнала.Этот тип стратегии можно найти здесь: http://www.almostinfinite.com/memtrack.html

Каков наилучший способ отследить это использование в связанной в сторонней библиотеке?Я предполагаю, что смогу отслеживать использование памяти до и после вызовов функции, верно?В моем сценарии макроса / перегрузки я могу просто отслеживать размер запросов, чтобы выяснить, сколько памяти запрашивается.Как бы я мог сказать, сколько использует сторонняя библиотека?Я также понимаю, что «бесплатное» отслеживание на самом деле не дает вам никакого представления о том, сколько кода используется в конкретный момент времени, поскольку оно не обязательно возвращается в ОС.Я ценю любое обсуждение этого вопроса.

Я действительно не хочу использовать какие-либо инструменты профилирования памяти, такие как Totalview или valgrind, , потому что они обычно делают много других вещей (проверка границ и т. Д.)кажется, что программное обеспечение работает очень медленно.Другая причина этого заключается в том, что я хочу, чтобы это было несколько поточно-ориентированным - программное обеспечение использует MPI, который, как я считаю, порождает процессы.Я собираюсь попытаться профилировать это в режиме реального времени, чтобы я мог выгружать файлы журналов или что-то, что может быть прочитано другим процессом, чтобы визуализировать использование памяти во время работы программного обеспечения.Это также в первую очередь будет выполняться в среде Linux.

Спасибо

Ответы [ 7 ]

1 голос
/ 06 июля 2011

Если вы не хотите использовать «внешний» инструмент, вы можете попробовать использовать такие инструменты, как:

  • mtrace

    Устанавливает обработчики для malloc, realloc и free и регистрирует каждую операцию в файл. См. Википедию, которую я выложил для примеров использования кода.

  • пооддержка

    Это библиотека, которую вы можете использовать в своем коде, и она может обнаруживать утечки памяти, отдельные ошибки и использование неправильных адресов. Вы также можете отключить его во время компиляции с -DDMALLOC_DISABLE.

Во всяком случае, я бы предпочел не использовать этот подход. Вместо этого я предлагаю вам попробовать провести стресс-тестирование вашего приложения во время его запуска на тестовом сервере под valgrind (или любым другим аналогичным инструментом) и убедиться, что вы правильно распределяете память, а затем позволить приложению работать без какой-либо проверки выделения памяти на производстве. чтобы максимизировать скорость. Но на самом деле это зависит от того, что делает ваше приложение и каковы ваши потребности.

1 голос
/ 30 июля 2015

Может быть, вам поможет опция компоновщика --wrap = symbol.Действительно хороший пример можно найти здесь: man ld

1 голос
/ 03 июня 2011

Вы можете попробовать Google PerfTools 'Heap-Profiler:

http://google -perftools.googlecode.com / svn / trunk / doc / heapprofile.html

Это очень легкий;он буквально заменяет malloc / calloc / realloc / free для добавления кода инструментария.Он в основном тестировался на платформах Linux.

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

1 голос
/ 01 июня 2011

Чтобы отслеживать потребление памяти моими программами в Linux в реальном времени, я просто читаю /proc/[pid]/stat. Это довольно легкая операция, которая может быть незначительной в вашем случае, если сторонняя библиотека, которую вы хотите отслеживать, выполняет последовательную работу. Если вы хотите иметь информацию о памяти во время работы сторонней библиотеки, вы можете прочитать файл stat в независимом потоке или в другом процессе. (Пик памяти редко добавляется до или после вызова функции! ...)

Что касается CUDA / GPU, я думаю, gDEBugger может вам помочь. Я не уверен, но анализатор памяти не сильно влияет на производительность.

1 голос
/ 01 июня 2011

Может быть valgrind и инструмент Massif?

0 голосов
/ 06 июля 2011

Я считаю, что на этот вопрос есть два очень отдельных ответа.Один для C / C ++ земли.И секунда для земли CUDA.

На процессоре:

Я написал свои собственные замены для новых и удаленных.Они были ужасно медленными и мало помогали.Я использовал totalview.Мне нравится totalview для отладки OpenMP, но я согласен очень медленно для отладки памяти.Я никогда не пробовал Вальгринд.Я слышал подобные вещи.

Единственный инструмент отладки памяти, с которым я столкнулся, стоит того, чтобы его попробовать - это Intel Parallel Inspector's Memory Checker. Примечание: будучи студентом, я смог получить дешевую лицензию на образование. Тем не менее, это удивительно.Мне потребовалось двенадцать минут, чтобы найти утечку памяти, скрытую в полмиллиона строк кода - я не выпускал брошенный объект ошибки, который я поймал и проигнорировал.Мне так нравится этот кусок программного обеспечения, что когда мой raid не удался / Win 7 съел мой компьютер (думаю, autoupdate и raid rebuild одновременно), я остановил все и восстановил компьютер, потому что я знал, что мне потребуется меньше времени для восстановления двойной загрузки(48 часов), чем было бы найти утечку памяти другим способом. Если вы не верите моим странным утверждениям, загрузите ознакомительную версию .

На графическом процессоре:

Iдумаю тебе не повезло.Для всех проблем с памятью в CUDA мне пришлось по-настоящему вырастить свои собственные инструменты и оболочки около cudaMalloc и т. Д. Это не красиво.nSight действительно что-то покупает, но на данный момент, не намного больше, чем просто «вот сколько вы выделили riiiight сейчас. И на этом грустном замечании почти каждая проблема с производительностью, с которой я столкнулся в CUDA, напрямую зависела от моего доступа к памятишаблоны (тот или другой размер блока нити).

0 голосов
/ 31 мая 2011

Вы можете использовать профилировщик, включенный в Visual Studio 2010 Premium и Ultimate.

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

...