Является ли Objective C достаточно быстрым для DSP / аудио программирования

Question

Я добился определенного прогресса в программировании звука для iPhone. Сейчас я занимаюсь настройкой производительности, пытаясь понять, смогу ли я выжать больше из этой маленькой машины. Запустив Shark, я вижу, что значительная часть моего процессора (16%) съедается objc_msgSend. Я понимаю, что могу несколько ускорить это, сохраняя указатели на функции (IMP), а не вызывая их с помощью нотации [object message]. Но если я собираюсь пройти через все эти неприятности, мне интересно, может быть, мне лучше использовать C ++.

Есть мысли по этому поводу?

Answer 1

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

Платформа Accelerate на OS X, например, является отличной высокопроизводительной библиотекой Objective C. Он использует только стандартные вызовы функций C99, и вы можете вызывать их из кода Objective C без каких-либо переносов или косвенных ссылок.

Answer 2

Проблема с Objective-C и такими функциями, как DSP, заключается не в скорости как таковой, а в неопределенности того, когда возникнут неизбежные узкие места.

Все языки имеют узкие места, но в статически связанных языках, таких как C ++, вы можете лучше предсказать, когда и где в коде они возникнут. В случае связывания во время выполнения Objective C время, необходимое для поиска подходящего объекта, время, необходимое для отправки сообщения, не обязательно медленное, но оно является переменным и непредсказуемым. Гибкость Objective-C в пользовательском интерфейсе, управлении данными и многократном использовании позволяет справиться с этим в случае жесткой синхронизации задач.

Большая часть обработки звука в Apple API выполняется на C или C ++ из-за необходимости ограничивать время выполнения кода. Тем не менее, его легко смешивать Objective-C, C и C ++ в одном приложении. Это позволяет вам выбрать лучший язык для выполнения ближайшей задачи.

Answer 3

Является ли Objective C достаточно быстрым для программирования DSP / аудио

Рендеринг в реальном времени

Определенно нет . Среда выполнения Objective-C и ее библиотеки просто не предназначены для требований воспроизведения звука в реальном времени. Дело в том, что практически невозможно гарантировать, что использование среды выполнения ObjC или библиотек, таких как Foundation (или даже CoreFoundation), не приведет к тому, что ваш рендерер пропустит крайний срок.

Распространенным случаем является блокировка - даже простое выделение кучи (malloc, new / new[], [[NSObject alloc] init]), вероятно, потребует блокировки.

Использование ObjC означает использование библиотек и среды выполнения, которые предполагают, что блокировки допустимы в любой точке их выполнения. Блокировка может приостановить выполнение вашего потока рендеринга (например, во время обратного вызова рендеринга) в ожидании получения блокировки. Тогда вы можете пропустить крайний срок рендеринга, потому что ваш поток рендеринга задерживается, что в итоге приводит к выпадению / сбоям.

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

Вот хорошее введение: http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

Оффлайн рендеринг

Да, это было бы приемлемо быстро в большинстве сценариев для высокоуровневого обмена сообщениями. На более низких уровнях я рекомендую не использовать ObjC, потому что это было бы расточительно - рендеринг мог бы занять много, много раз дольше, если обмен сообщениями ObjC используется на этом уровне (по сравнению с реализацией C или C ++).

См. Также: Примет ли мое приложение для iPhone снижение производительности, если я использую Objective-C для низкоуровневого кода?

Answer 4

objc_msgSend - это просто утилита. Стоимость отправки сообщения - это не только стоимость отправки сообщения. Это стоимость выполнения всего, что инициирует сообщение. (Точно так же, как истинная стоимость вызова функции - это включительно стоимость, включая ввод / вывод, если есть.)

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

Вы можете обнаружить, что звоните им больше, чем должны.

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