Прирост производительности в C ++ / CLI

Question

Я давно начал с простого C, затем перешел на C ++, и теперь я сталкиваюсь с C ++ / CLI. Как фанат производительности, я всегда пытаюсь втиснуть последнее падение производительности в каждую строку кода. В настоящее время я нахожусь в проекте, который имеет смысл делать в основном в VB.Net (простота, доступность ресурсов и т. Д.), Но у меня есть несколько моментов, которые очень чувствительны к производительности, и я планировал выполнить эти части в C ++ / CLI , Однако только небольшая его часть может быть извлечена из управляемого кода, в то время как остальная часть должна быть управляемой. Вопрос в том, можно ли ожидать повышения производительности от написания управляемой функции на C ++ / CLI по сравнению с C # или VB.Net? Из того, что я мог понять из документов, которые я читал, кажется, что единственным преимуществом является то, что управляемый / неуправляемый thunking легче. Это тот случай? Потому что я даже не могу хранить дескрипторы в неуправляемых массивах или структурах (которыми я мог бы манипулировать быстрее), например:

String ^ mystr = "Oh, my!";
Object ^ myarray[10];
myarray[0] = mystr; // Can't event be casted to void*, int, HANDLE...
// (however, handles do have a sizeof() == 4 in Win32)
// (I don't expect the handle to behave like a pointer; just stay as handle)

Answer 1

C ++ / CLI управляется - он компилируется в тот же MSIL, что и любой другой язык .net. если скорость для вас важна, напишите критический бит в нативный dll и извлеките его из своего приложения на vb.net (отложите отсчет thunk, и все будет в порядке).

хотя tbh, id сначала профилируйте код, чтобы увидеть, действительно ли это необходимо, а не просто преждевременной оптимизации. MSIL в любом случае можно / скомпилировать в собственный код - реальный вопрос заключается в том, насколько оптимизирован .net JITer так же хорошо, как и собственный компилятор c / c ++.

Answer 2

Я тоже фанат производительности, и я узнал, что

1. Я не задаю этот вопрос, пока не узнаю, где проблемы с производительностью,

2. Как только я узнаю, где они находятся, мне не нужно спрашивать, потому что я могу легко это выяснить, потому что а) все скомпилированные языки генерируют ассемблер или промежуточный язык, на который я могу смотреть, и б) может запустить его 10 ^ 6 раз и просто часы его.

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

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

** Пример: предположим, что программе требуется 10 секунд. Предположим, есть две проблемы (вы не знаете, пока не посмотрите), и они занимают 50% и 30% соответственно. Вы исправляете первый, и время падает до 5 секунд. Теперь вторая проблема потребляет 60%, потому что общее время уменьшилось, так что это намного легче обнаружить. Исправьте это, и время падает до 2 секунд - 5-кратное ускорение. Чем больше проблем, тем драматичнее возможное ускорение. Можно сомневаться, что у них такие большие проблемы, и если да, то выборка докажет или опровергнет это.

Answer 3

Кстати, чтобы хранить дескрипторы в неуправляемых частях памяти, мне просто нужно было использовать структуру GCHandle или gcroot .

Answer 4

Нет никакого преимущества в производительности, поскольку C ++ / CLI компилируется в MSIL, как C # и VB.NET. Вы можете написать несколько простых тестовых функций на VB и C ++ / CLI, чтобы убедиться в этом.

Answer 5

Повышение производительности достигается за счет смешивания неуправляемого кода с управляемой сборкой. C ++ / cli делает это очень легко. Попробуйте вызвать c ++ с помощью pinvoke через c # или vb.net ... вам придется либо обернуть c ++ во внешние вызовы c, либо вызвать c ++ по его искаженному имени. Также вы получаете выигрыш в производительности от оптимизированных компиляторов Microsoft C ++, что довольно неплохо. Если вы не смешиваете неуправляемый код, то повышение производительности не происходит, поскольку все это компилируется в MSIL, как уже упоминали другие.

Answer 6

Хотя компилятор C ++ / CLI может не обеспечивать более высокую производительность для прямого перевода кода, существует ряд функций C ++, которые могут дать огромные преимущества в производительности даже в управляемом коде.

Большой шаблон. Код регенерируется и независимо оптимизируется для каждой комбинации параметров шаблона. В то время как обобщенные формы .NET часто запрещают даже самые простые вставки, преобразование в шаблоны C ++ / CLI предоставляет дополнительные возможности оптимизации, а также метапрограммы специализации и времени компиляции, которые не имеют эквивалента ни в одном другом языке .NET.

Answer 7

Единственный прирост производительности, который вы можете увидеть с C ++ / CLI, - это смешивание собственного и управляемого кода. C ++ / CLI позволяет вам вызывать собственные методы для критически важных для кода участков кода с меньшими издержками, чем VB.Net. Я бы не рекомендовал переключаться между нативным и управляемым везде, так как все еще есть штраф, но передача управления нативному коду для части кода, связанного с производительностью, приемлема.