Профилирование и оптимизация патчей и внешних компонентов PureData

Question

Я работаю над синтезатором, встроенным в Pd, и запускаю его на BeagleBone Black. Для этого я написал несколько абстракций и два внешних. В настоящий момент синтезатор является монофоническим и использует 100% процессор при запуске, вызывая множество звуковых кликов и артефактов. Примерно через 5 секунд он «стабилизируется» до 75% CPU, а латентность и звук довольно хороши.

Теперь мне нужно сделать synth polyphonic, поэтому время процессора должно быть освобождено для дополнительных голосов. Для этого я собираюсь создать Pd с отладочными символами и запустить мой патч через профайлер, такой как Callgrind/KCacheGrind, чтобы попытаться выяснить, где происходит наибольшее потребление ЦП и его оптимизация.

Может ли кто-нибудь поделиться любыми методами или советами, используемыми для оптимизации патчей и внешних ссылок Pd? Существуют ли какие-либо инструменты, специфичные для Pd для такого рода задач? Любая причина, по которой мой подход будет работать или не будет работать?

Answer 1

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

, как для в патче профилирования, лучший Pd предлагает это [realtime] объекта, который можно использовать для измерения времени, необходимого (настенных часов времени, не Дискретных, который должен быть равен нулем), чтобы выполнить определенную операцию в домен сообщения. Однако это невозможно использовать для сигнала объектов !!

Вот пример профилировать полное выполнение поддерева (в пределах [pd complicated] subpatch) и несколько отдельных объектов (в пределах [pd complex] subpatch)

Из вашего описания, кажется, что ваш патч тратит много времени во время инициализации (максимизация процессора, поэтому требуется некоторое время, чтобы опуститься ниже 100%), что, скорее всего, указывает на проблемы в домене сообщений.

Что касается домена сигнала, то типичные проблемы включают в себя повторное блокирование до небольших размеров блоков ([block~ 1]) и вычисление неиспользуемых голосов (выключите их с помощью [switch~], если они добавят к выходу сигнала).

Answer 2

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

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

Удачи вам!