Различие в производительности между C++ и C# для математики

For straight mathematical functions asking if C# is faster than C++ is not the best question. What you should be asking

Is the assembly produced by the CLR JITer more or less efficient than assembly generated by the C++ compiler

The C# compiler has much less influence on the speed of purely mathmatical operations than the CLR JIT does. It would have almost identical performance as other .Net languages (such as VB.Net if you turn off overflow checing).

Здесь есть обширные тесты:

http://shootout.alioth.debian.org/ u32q / benchmark.php? test = all & lang = csharp & lang2 = gpp & box = 1

Обратите внимание, что здесь сравнивается Mono JIT с C ++. AFIAK нет обширных тестов реализации Microsoft, поэтому почти все, что вы услышите, - это слухи. : (

C# will be slower in general, but not significantly so. In some cases, depending on the structure of the code, C# can actually be faster, as JIT analysis can frequently improve the performance of a long-running algorithm.

Edit: Here's a nice discussion of C# vs C++ performance

Edit 2:

"In general" is not really accurate. As you say, the JIT compiler can actually turn your MSIL into faster native code that the C++ compiler because it can optimize for the hardware it is running on.

You must admit, however, that the act of JIT compiling itself is resource intensive, and there are runtime checks that occur in managed code. Pre-compiled and pre-optimized code will always be faster than just JITted code. Every benchmark comparison shows it. But long-running processes that can have a fair amount of runtime analysis can be improved over pre-compiled, pre-optimized native code.

So what I said was 100% accurate. For the general case, managed code is slightly slower than pre-compiled, pre-optimized code. It's not always a significant performance hit, however, and for some cases JIT analysis can improve performance over pre-optimized native code.

Я думаю, вы задаете неправильный вопрос. Вы должны спросить, может ли C ++ превзойти семейство языков .NET в математических вычислениях. Взгляните на сравнение времени F # для Runge Kutta

Вы не очень хорошо определяете "математически интенсивный" (преуменьшение для: совсем нет).

Попытка поломки:

• По базовым функциям Sin / Cos / Log не ожидал большой разницы.

• Что касается линейной алгебры (матриц), я бы ожидал, что .NET потеряет силу, проверка границ (всегда принудительно) для массивов оптимизируется только при некоторых обстоятельствах.

Вероятно, вам придется сравнить что-то близкое к предполагаемому домену.

Я бы подумал об использовании Mono.Simd для ускорения некоторых операций. Минус в том, что на MS runtime не разгоняется.

Я недавно не проверял, но в последний раз, когда я проверял, лицензионное соглашение Microsoft для среды выполнения .NET требовало от вас согласия НЕ публиковать какие-либо тесты производительности. Это имеет тенденцию ограничивать объем публикуемой достоверной информации.

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

Изменить: Немного присмотревшись, лицензия изменилась (по сути, очень давно). текущие условия скажем, вам разрешено публиковать тесты производительности - но только , если вы выполняете их условия. Некоторые из этих условий кажутся (мне) почти невыполнимыми. Например, вы можете публиковать только при условии: «ваше тестовое тестирование было выполнено с использованием всех настроек производительности и рекомендаций, изложенных в документации по продукту и / или на веб-сайтах поддержки Microsoft». Учитывая размер и количество веб-сайтов Microsoft, я не понимаю, как у кого-то есть шанс быть уверенным в том, что они следуют всем рекомендациям, которые они могут предоставить.

Хотя эта веб-страница говорит о .NET 1.1, более новых лицензиях похоже, тоже ссылаются на это.

Итак, то, что я вспомнил, было технически неверным, но в любом случае эффективно правильным.

Для базовых функций математической библиотеки особой разницы не будет, потому что C # будет вызывать тот же скомпилированный код, что и C ++. Для более интересной математики, которую вы не найдете в математической библиотеке, есть несколько факторов, ухудшающих C #. Текущая JIT не поддерживает инструкции SSE, к которым у вас был бы доступ в C ++.