С++ CLI. Являются ли родные части написаны в чистом С++, но скомпилированы в CLI так же быстро, как чистый родной С++?

Я хочу делегировать звуковые вычисления на уровень С++, но обрабатывать и редактировать аудиоконтент через графический интерфейс WPF.

У меня был краткий взгляд на С++/CLI, и я хотел знать:

Должен ли я использовать С++/CLI в качестве промежуточного уровня между С# GUI и управлением аудио на С++.
или я должен просто поместить свой код в С++/CLI и ожидать, что он будет скомпилирован таким же образом, таким образом, как эффективный.

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

Ответ 1

В С++/CLI управляемые типы (ref class например) и их члены скомпилированы в MSIL. Это означает отсутствие использования SIMD и гораздо меньшую оптимизацию (по крайней мере, в текущей версии .NET, и причины, данные Microsoft, не меняются в ближайшее время, хотя они могут изменить свою оценку компромиссов).

С другой стороны, родные типы могут быть скомпилированы либо в MSIL, либо в собственный машинный код. Хотя Visual С++ не имеет лучшего оптимизатора С++ в мире, это очень хорошо. Поэтому моя рекомендация заключалась бы в компиляции с собственным кодом. Visual С++ будет использовать взаимодействие С++ при вызове между управляемым и собственным кодом, что очень эффективно (это та же технология internalcall, используемая для всех встроенных функций .NET, таких как конкатенация строк).

Чтобы это произошло, вы можете либо поместить свой критический по времени код в отдельный объектный файл (а не отдельную DLL!), пусть компоновщик объединяет управляемый и неуправляемый код вместе в сборку "смешанный режим" ), скомпилированный без /clr или скопируйте его с помощью #pragma managed(push, off)... #pragma managed(pop). В любом случае вы получите максимальную оптимизацию и сможете использовать SIMD-функции для очень быстрого кода.

Ответ 2

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

Итак, это зависит от проблемы: самой простой проблемой будет интерфейс, который отправляет немного примитивных данных на уровне С++/CLI, обрабатывает время LONG, а затем отправляет немного данных назад (например, минимальные издержки на сортировку), Если ваш алгоритм требует более широкого взаимодействия на уровне С++/CLI, он становится намного более сложным.

Преимущество "All С#" или "All Managed" заключается в (1) пропуске этого маршаллингового слоя (который является накладным и иногда утомительным в зависимости от работы) и (2) оптимизации времени выполнения, который движок .NET может сделать для конкретного компьютера, на котором выполняется код (который у вас не может быть с собственным C/С++ или неуправляемым кодом).

Я согласен с другими комментариями в этом потоке, которые вы должны/должны "протестировать" его в своих сценариях. "Большой" слой С++/CLI с чувствительным к производительности переходом очень сложно сделать из-за "бокса/распаковки", который (автоматически) возникает, когда вы продолжаете прыгать между управляемыми/неуправляемыми.

Наконец, конечная разница в производительности между гибридным "управляемым/неуправляемым" дизайном и "все-управляемым" дизайном связана с компромиссами между: может ли .NET-движок сделать оптимизацию для конкретной машины кода .NET( например, принимая преимущества конкретных для машины потоков/ядер/регистров), больше, чем "чистый собственный" код (который связан с сборкой смешанного режима) способен обрабатывать FAST, минуя движок .NET(который является переводчика)?

Правда, хорошо написанный собственный код может "обнаруживать" потоки процессора, но обычно не может обнаруживать регистры, специфичные для машины (если они не скомпилированы для этой целевой платформы). Напротив, собственный код не имеет "накладных расходов" на пути выполнения среды выполнения .NET, которая представляет собой просто виртуальную машину (которая может быть "ускорена" с помощью Just-In-Time компиляции некоторой логики в ее конкретное базовое оборудование).

Сложная проблема. Сожалею. ИМХО, на этот тип проблем просто нет простых ответов, если "проблема с эффективностью" - это ваша проблема.

Ответ 3

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

Ответ 4

Из моего собственного тестирования, которое я сделал по теме, С# быстрее, чем собственный С++ для алгоритмов. Единственный недостаток заключается в том, что для С# существует меньше алгоритмов, чем С++ в Интернете.