Должен ли я переписать свои подпрограммы DSP на C / C ++ или я хорошо справляюсь с небезопасными указателями на C #?

Question

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

Получу ли я какое-либо преимущество в производительности от переписывания этих подпрограмм на C или C ++ или я должен придерживаться небезопасных указателей? Я хотел бы знать, что небезопасные указатели приносят в таблицу с точки зрения производительности, по сравнению с C / C ++.

РЕДАКТИРОВАТЬ: Я не делаю ничего особенного внутри этих подпрограмм, просто обычные вещи DSP: кеширующие передачи данных из одного массива в другой с большим количеством умножений, сложений, сдвигов битов и т. Д. В пути. Я ожидаю, что подпрограммы C / C ++ будут выглядеть почти так же (если не идентично), как их аналоги в C #.

РЕДАКТИРОВАТЬ: Большое спасибо всем за все умные ответы. Что я узнал, так это то, что я не получу никакого значительного прироста производительности, просто сделав прямой порт, если не произойдет какая-либо оптимизация SSE. Предполагая, что все современные компиляторы C / C ++ могут воспользоваться этим, я с нетерпением жду возможности попробовать. Если кто-то заинтересован в результатах, просто дайте мне знать, и я опубликую их где-нибудь. (Хотя может занять некоторое время).

Answer 1

Ваш вопрос в значительной степени философский. Ответ таков: не оптимизируйте, пока вы не профилируете.

Вы спрашиваете, получите ли вы улучшение. Хорошо, вы получите улучшение на N процентов. Если этого достаточно (например, вам нужен код, который выполняется 200 раз за 20 миллисекунд на некоторой встроенной системе), то все в порядке. Но что, если этого недостаточно?

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

Answer 2

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

Answer 3

Я бы предположил, что если в вашем коде DSP есть какие-либо алгоритмы, которые нуждаются в для оптимизации, то вы действительно должны писать их на ассемблере, а не на C или C ++.

В целом, при использовании современных процессоров и аппаратного обеспечения не так много сценариев, которые требуют или требуют усилий, связанных с оптимизацией. Вы на самом деле выявили какие-либо проблемы с производительностью? Если нет, то, вероятно, лучше придерживаться того, что у вас есть. Небезопасный C # вряд ли будет значительно медленнее, чем C / C ++, в большинстве случаев простой арифметики.

Рассматривали ли вы C ++ / CLI? Тогда вы можете получить лучшее из обоих миров. Это даже позволит вам использовать встроенный ассемблер, если потребуется.