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

Я хотел бы предисловие к этому, я не пытаюсь начать бой. Мне было интересно, есть ли у кого-нибудь хорошие ресурсы, которые сравнивали С++ и С# для математически интенсивного кода? У меня возникает впечатление, что С# должен быть значительно медленнее, но у меня нет никаких доказательств этого чувства. Мне было интересно, если кто-нибудь здесь когда-либо сталкивался с исследованием или сам тестировал это? Я планирую запустить некоторые тесты самостоятельно, но хотел бы знать, сделал ли кто-нибудь это строгим образом (google показывает очень мало). Спасибо.

EDIT: для интенсивного я имею в виду много греха /cos/exp, происходящего в плотных циклах

ОТВЕТЫ

Ответ 1

Мне приходится периодически сравнивать производительность основной математики в среде исполнения и языках как часть моей работы.

В моем последнем тесте производительность С# по сравнению с моим оптимизированным контрольным ядром С++ под ключевым эталоном — преобразование длинного массива из 4d векторов с помощью 4d-матрицы с конечным этапом нормализации; С++ был примерно в 30 раз быстрее, чем С#. Я могу получить максимальную пропускную способность одного вектора каждые 1,8 нс в моем коде на С++, тогда как С# выполнил работу примерно в 65 нс на вектор.

Это, конечно, специализированный случай, и С++ не наивна: он использует программную конвейерную обработку, SIMD, предварительную выборку кеша, целые девять ярдов микрооптимизации.

Ответ 2

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

Изменить: Здесь приятно обсуждение производительности С# vs С++

Изменить 2:

"В общем" не очень точно. Как вы говорите, компилятор JIT может фактически превратить ваш MSIL в более быстрый собственный код, что компилятор С++, потому что он может оптимизировать для аппаратного обеспечения, на котором он работает.

Однако вы должны признать, что сам процесс компиляции JIT является ресурсоемким, и в управляемом коде есть проверки выполнения. Предварительно скомпилированный и предварительно оптимизированный код всегда будет быстрее, чем только JIT-код. Это показывает все сравнительные сравнения. Но длительные процессы, которые могут иметь достаточный объем анализа времени выполнения, могут быть улучшены по предварительно скомпилированному предварительно оптимизированному собственному коду.

Итак, то, что я сказал, было на 100% точным. В общем случае управляемый код немного медленнее, чем предварительно скомпилированный, предварительно оптимизированный код. Однако это не всегда приводит к существенному результату, и в некоторых случаях JIT-анализ может повысить производительность по сравнению с предварительно оптимизированным собственным кодом.

Ответ 3

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

Является ли сборка, созданная CLR JITer более или менее эффективной, чем сборка, сгенерированная компилятором С++

Компилятор С# оказывает гораздо меньшее влияние на скорость чисто математических действий, чем CLR JIT. Он будет иметь почти идентичную производительность, как и другие .Net-языки (например, VB.Net, если вы отключите переполнение переполнения).

Ответ 5

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

Ответ 6

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

Попытка пробоя:

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Итак, то, что я помню, было технически ошибочным, но в действительности все равно правильно.

Ответ 9

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