Повысит ли производительность C++/CLI + C++ Native? [закрытый]

Когда я свяжу статический lib с C++ / CLI, он не станет управляемым кодом? Значит, он не попадет под CLR.

Нет, не обязательно. В C++ / CLI все управляемые типы будут скомпилированы в MSIL, и код будет выполняться в среде CLR. Собственные типы компилируются либо в MSIL, либо в машинный код, в зависимости от параметров компилятора :

• параметр /clr генерирует смесь машинного и управляемого кода.
• опция /clr:pure генерирует управляемая сборка, которая может содержать собственные типы, скомпилированные в MSIL. Это работает в основном как код C#, скомпилированный с параметром /unsafe.
• параметр /clr:safe создает управляемую сборку, которая не содержит собственного кода. Это работает в основном как код C#, скомпилированный без опции /unsafe.

Повышает ли мою производительность использование C++(Native) static lib с C++/CLI в C#? Не могу ли я добиться написания кода на самом C#, а не на родном языке код.

Как и все вопросы оптимизации, ответ заключается в том, что это зависит. С одной стороны, машинный код часто быстрее управляемого и может быть более высоко оптимизирован (например, с использованием SIMD). С другой стороны, существует хит производительности, связанный со сборками со смешанным режимом. Реализация взаимодействия C++ обычно довольно быстра (конечно, намного быстрее, чем P/Invoke из C#), но если выгоды, которые вы получаете от компиляции в машинный код, недостаточно существенны, это может быть все равно не стоит того. Единственный способ действительно узнать-это проверить оба варианта.

Управляемый код часто получает плохую оценку, особенно от опытных программистов C++, но правда в том, что хорошо написанный код C# может быть таким же быстрым, если не быстрее, чем эквивалентный родной код C++. Это также намного легче выстрелить себе в ногу в C++, поэтому если у вас есть команда разработчиков, которые являются экспертами C# и не обязательно экспертами C++, вы, вероятно, закончите плохо написанным и медленным Код C++. Наконец, когда остальная часть вашего проекта находится в C#, снижение затрат на обслуживание может означать, что дажеаналогичная производительность приемлема.