Является ли С# действительно медленнее, чем С++?

Ответ 1

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

С чисто теоретической точки зрения, вероятно, есть простой ответ на этот вопрос: там (возможно) ничего не говорится о С#, который действительно мешает ему быть таким же быстрым, как С++. Тем не менее, несмотря на теорию, есть некоторые практические причины, по которым в некоторых случаях она медленнее в некоторых вещах.

Я рассмотрю три основные области различий: языковые функции, выполнение виртуальной машины и сбор мусора. Последние два часто идут вместе, но могут быть независимыми, поэтому я буду смотреть на них отдельно.

Особенности языка

С++ уделяет большое внимание шаблонам и функциям системы шаблонов, которые в основном предназначены для того, чтобы максимально возможное время выполнения во время компиляции, поэтому с точки зрения программы они "статичны". " Мета-программирование шаблонов позволяет выполнять произвольные вычисления во время компиляции (I.e., система шаблонов - полная Тьюринга). Таким образом, практически все, что не зависит от ввода от пользователя, может быть вычислено во время компиляции, поэтому во время выполнения это просто константа. Однако вход в это может включать такие вещи, как информация о типе, поэтому многое из того, что вы делаете посредством отражения во время выполнения на С#, обычно выполняется во время компиляции с помощью метапрограммирования шаблонов на С++. Существует определенно компромисс между скоростью выполнения и универсальностью, хотя - какие шаблоны могут делать, они статически, но они просто не могут делать все, что может отразить.

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

Виртуальная машина

Как и почти любая разумно современная VM, Microsoft для .NET может и будет делать JIT (так называемую "динамическую" ) компиляцию. Однако это представляет собой ряд компромиссов.

В первую очередь оптимизация кода (как и большинство других проблем оптимизации) в основном является NP-полной проблемой. Для чего-либо, кроме действительно тривиальной/игрушечной программы, вы почти гарантированы, что не будете по-настоящему "оптимизировать" результат (т.е. Вы не найдете истинного оптимума) - оптимизатор просто сделает код лучше, чем он был ранее. Однако довольно много известных оптимизаций требуют значительного времени (и, чаще всего, памяти) для выполнения. С компилятором JIT пользователь ждет, пока компилятор работает. Большинство из более дорогих методов оптимизации исключены. Статическая компиляция имеет два преимущества: во-первых, если она медленная (например, создание большой системы), она обычно выполняется на сервере, и никто не тратит время на ее ожидание. Во-вторых, исполняемый файл может быть создан один раз и многократно используется многими людьми. Первый минимизирует затраты на оптимизацию; вторая амортизирует гораздо меньшую стоимость за гораздо большее количество исполнений.

Как упоминалось в первоначальном вопросе (и во многих других веб-сайтах), компиляция JIT имеет возможность более глубокого осознания целевой среды, которая должна (по крайней мере теоретически) компенсировать это преимущество. Нет сомнения, что этот фактор может компенсировать по крайней мере часть недостатка статической компиляции. Для нескольких довольно специфических типов кода и целевых сред он может даже перевесить преимущества статической компиляции, иногда довольно резко. Однако, по крайней мере, в моих тестах и ​​опыте это довольно необычно. Оптимизация, зависящая от целей, по-видимому, либо делает довольно небольшие различия, либо может применяться (автоматически, во всяком случае) только к довольно конкретным типам проблем. Очевидно, что это произойдет, если бы вы использовали относительно старую программу на современной машине. Старая программа, написанная на С++, вероятно, была бы скомпилирована в 32-разрядный код и будет продолжать использовать 32-разрядный код даже на современном 64-битном процессоре. Программа, написанная на С#, была бы скомпилирована в байт-код, который VM затем скомпилирует в 64-разрядный машинный код. Если эта программа получила существенную выгоду от работы в виде 64-битного кода, это может дать существенное преимущество. За короткое время, когда 64-битные процессоры были довольно новыми, это получило справедливую сумму. Недавний код, который, вероятно, будет полезен для 64-битного процессора, обычно будет скомпилирован статически в 64-разрядный код.

Использование виртуальной машины также имеет возможность улучшить использование кеша. Инструкции для виртуальной машины часто более компактны, чем инструкции на машинах. Более того, они могут вписываться в заданный объем кэш-памяти, поэтому у вас есть больше шансов на то, что какой-либо данный код будет в кеше при необходимости. Это может помочь интерпретировать выполнение кода VM более конкурентоспособным (с точки зрения скорости), чем изначально ожидали большинство людей - вы можете выполнить множество инструкций по современному процессору за время, затраченное на пропуску кеша.

Также стоит упомянуть, что этот фактор не обязательно является разным. Там ничего не мешает (например) компилятор С++ производить вывод, предназначенный для работы на виртуальной машине (с или без JIT). Фактически, Microsoft С++/CLI почти что - (почти) соответствующий С++-компилятор (хотя и с большим количеством расширений), который производит вывод, предназначенный для работы на виртуальной машине.

Обратное также верно: Microsoft теперь имеет .NET Native, который компилирует код С# (или VB.NET) в собственный исполняемый файл. Это дает производительность, которая в целом намного больше похожа на С++, но сохраняет функции С#/VB (например, С#, скомпилированный в собственный код, все еще поддерживает отражение). Если у вас есть высокопроизводительный код С#, это может быть полезно.

Сбор мусора

Из того, что я видел, я бы сказал, что сбор мусора является самым бедным - понятным из этих трех факторов. Для очевидного примера здесь возникает вопрос: "GC не добавляет слишком много накладных расходов, если вы не создаете и не уничтожаете тысячи объектов [...]". На самом деле, если вы создаете и уничтожаете тысячи объектов, накладные расходы из сборщика мусора обычно будут довольно низкими..NET использует поглотитель поколений, который представляет собой множество копировальных коллекторов. Сборщик мусора работает, начиная с "мест" (например, регистров и стека выполнения), что указатели/ссылки, как известно, доступны. Затем он "преследует" эти указатели на объекты, которые были выделены в куче. Он исследует эти объекты для дальнейших указателей/ссылок, пока он не выполнил все их до целых цепей и не обнаружил все доступные (по крайней мере потенциально) объекты. На следующем шаге он принимает все объекты, которые (или, по крайней мере, могут быть) использованы, и уплотняет кучу, копируя все их в смежный кусок на одном конце управляемой памяти в куче. Остальная часть памяти затем свободна (по умолчанию должны выполняться финализаторы по модулю, но, по крайней мере, в хорошо написанном коде, они достаточно редки, что я буду игнорировать их на данный момент).

Это означает, что если вы создаете и уничтожаете множество объектов, сборка мусора добавляет очень мало накладных расходов. Время, затрачиваемое циклом сбора мусора, почти полностью зависит от количества объектов, которые были созданы, но не уничтожены. Главным следствием создания и уничтожения объектов в спешке является просто то, что GC должен работать чаще, но каждый цикл будет по-прежнему быстрым. Если вы создаете объекты и не уничтожаете их, GC будет работать чаще, и каждый цикл будет значительно медленнее, поскольку он тратит больше времени на точечные указатели на потенциально живущие объекты и тратит больше времени на копирование объектов, которые все еще используются.

Чтобы бороться с этим, очистка поколений работает в предположении, что объекты, которые остались "живыми" довольно долгое время, скорее всего, останутся живыми еще довольно долго. Исходя из этого, у него есть система, в которой объекты, которые выживают в некотором количестве циклов сбора мусора, получают "пожизненный", и сборщик мусора начинает просто предполагать, что они все еще используются, поэтому вместо того, чтобы копировать их в каждый цикл, он просто уходит они одни. Это достаточно допустимое предположение, достаточно частое, что поглощение поколений обычно имеет значительно меньшие накладные расходы, чем большинство других форм GC.

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

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

Бонус Тема: Тесты

Поскольку довольно много блогов, веб-сайтов, журнальных статей и т.д. претендуют на предоставление "объективных" доказательств в том или ином направлении, я положу свои двухценты на эту тему.

Большинство из этих тестов немного похожи на подростков, которые решают расы своих автомобилей, и тот, кто выигрывает, получает, чтобы держать обе машины. Веб-сайты отличаются одним решающим образом: парень, который публикует бенчмарк, получает возможность управлять обеими автомобилями. По каким-то странным шансам его машина всегда выигрывает, и все остальные должны довольствоваться "поверьте мне, я действительно ездил на вашем автомобиле так быстро, как это было бы".

Легко написать плохой тест, который дает результаты, которые означают почти ничего. Практически любой человек, обладающий навыками, необходимыми для разработки эталонного теста, который создает что-либо значимое, также обладает умением производить тот, который даст результаты, которые он решил, что хочет. На самом деле, вероятно, проще написать код для получения определенного результата, чем код, который действительно даст значимые результаты.

Как сказал мой друг Джеймс Канзе: "Никогда не доверяй бенчмарку, который ты не фальсифицировал".

Заключение

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

Как указывали другие, для большинства кодов скорость почти не имеет значения. Следствием этого (которое гораздо чаще игнорируется) является то, что в маленьком коде, где скорость имеет значение, это обычно имеет значение. По крайней мере, по моему опыту, для кода, где это действительно имеет значение, С++ почти всегда является победителем. Есть определенные факторы, которые способствуют С#, но на практике они, кажется, перевешиваются факторами, которые благоприятствуют С++. Конечно, вы можете найти тесты, которые будут указывать на результат по вашему выбору, но когда вы пишете реальный код, вы почти всегда можете сделать его быстрее на С++, чем на С#. Он мог бы (или не мог) брать больше навыков и/или усилий писать, но это практически всегда возможно.

Ответ 2

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

Ответ 3

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

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

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

Прекратите думать о производительности вашего кода. Начните строить значение.

Ответ 4

Около 2005 года два эксперта по оценке MS с обеих сторон родного/управляемого забора попытались ответить на один и тот же вопрос. Их метод и процесс по-прежнему увлекательны, и выводы все еще сохраняются сегодня - и я не знаю о какой-либо лучшей попытке дать обоснованный ответ. Они отметили, что обсуждение потенциальных причин различий в производительности является гипотетическим и бесполезным, и настоящая дискуссия должна иметь некоторую эмпирическую основу для воздействия таких различий в реальном мире.

Итак, Старый Новый Раймонд Чен и Рико Мариани установить правила для дружеского соревнования. В качестве контекста приложений для игрушек был выбран китайский/английский словарь: достаточно прост, чтобы кодироваться как хобби-проект, но достаточно сложный, чтобы продемонстрировать нетривиальные шаблоны использования данных. Правила стали простыми - Raymond закодировал простую реализацию на С++, Rico переместил ее на С# по строкам, без каких-либо сложностей, и обе реализации прошли тест. Затем последовало несколько итераций оптимизаций.

Подробнее здесь: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16.

Этот диалог титанов является исключительно образовательным, и я всем сердцем рекомендую погрузиться, но если вам не хватает времени или терпения, Джефф Атвуд скомпилировал нижние строки красиво:

В конце концов, С++ был в 2 раза быстрее - но изначально, он был на 13 раз медленнее.

Поскольку Rico подводит итоги:

Так мне стыдно от моего сокрушительного поражения? Едва. Управляемый код достигли очень хорошего результата для почти никаких усилий. Чтобы победить управляемая версия, Раймонд должен был:

• Напишите свой собственный файл /io stuff

• Напишите свой собственный класс строк

• Напишите свой собственный распределитель

• Напишите свое собственное международное сопоставление

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

Это мой опыт, еще 11 лет, и кто знает, сколько версий С#/С++ позже.

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

Ответ 5

С# быстрее, чем С++. Быстрее писать. Для времени выполнения ничто не сравнится с профилировщиком.

Но у С# не так много библиотек, как С++ может легко взаимодействовать.

И С# сильно зависит от окон...

Ответ 6

BTW, приложения с критическими по времени приложениями не кодируются на С# или Java, в основном из-за неопределенности того, когда будет выполняться сборка мусора.

В наше время скорость приложения или исполнения не так важна, как раньше. Графики разработки, правильность и надежность являются более приоритетными. Высокоскоростная версия приложения не годится, если у него много ошибок, сбоев много или хуже, упускается возможность выйти на рынок или развернуться.

Поскольку графики разработки являются приоритетными, появляются новые языки, которые ускоряют разработку. С# является одним из них. С# также помогает в правильности и надежности, удаляя функции из С++, которые вызывают общие проблемы: одним из примеров является указатель.

Различия в скорости выполнения приложения, разработанного с помощью С#, и одного, разработанного с использованием С++, на большинстве платформ незначительны. Это связано с тем, что узкие места исполнения не зависят от языка, но обычно зависят от операционной системы или ввода-вывода. Например, если С++ выполняет функцию в 5 мс, но С# использует 2 мс, а ожидание данных занимает 2 секунды, время, затрачиваемое на эту функцию, незначительно по сравнению с временем ожидания данных.

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

Ответ 7

Лучший способ взглянуть на это все медленнее, чем C/С++, потому что он абстрагируется, а не придерживается парадигмы палочки и грязи. Это называется системным программированием по какой-то причине, вы программируете против зерна или голого металла. Это также дает вам скорость, которую вы не можете достичь с помощью других языков, таких как С# или Java. Но, увы, C-корни - это все о том, как делать что-то тяжело, поэтому вы в основном собираетесь писать больше кода и тратить больше времени на его отладку.

C также чувствителен к регистру, также объекты на С++ также следуют строгим наборам правил. Например, фиолетовый конус для мороженого может не совпадать с конусом синего мороженого, хотя они могут быть конусами, которые они могут не принадлежать семье конусов, и если вы забудете определить, какой конус вы используете. Таким образом, свойства мороженого могут быть или не быть клонами. Теперь аргумент скорости, C/С++ использует метод стека и кучи, это тот, где голый металл получает это металл.

С помощью библиотеки boost вы можете достичь невероятных скоростей, к сожалению, большинство игровых студий придерживаются стандартной библиотеки. Другая причина этого может заключаться в том, что программное обеспечение, написанное на C/С++, имеет тенденцию быть массивным в размере файла, так как это гигантская коллекция файлов вместо одного файла. Также обратите внимание, что все операционные системы написаны на C, поэтому, как правило, почему мы должны задавать вопрос, что может быть быстрее?!

Также кеширование не быстрее, чем управление чистой памятью, извините, но это просто не отключается. Память - это что-то физическое, кеширование - это то, что делает программное обеспечение, чтобы добиться успеха. Можно также предположить, что без физической памяти кэширование просто не будет существовать. Это не лишает факта, что память должна управляться на определенном уровне независимо от того, является ли она автоматизированной или ручной.

Ответ 8

Зачем вам писать небольшое приложение, которое не требует многого для оптимизации на С++, если есть более быстрый маршрут (С#)?

Ответ 9

Получение точного ответа на ваш вопрос на самом деле невозможно, если вы не выполняете тесты на конкретных системах. Тем не менее, все же интересно подумать о некоторых фундаментальных различиях между языками программирования, такими как С# и С++.

Компиляция

Выполнение кода С# требует дополнительного шага, где код JIT'ed. Что касается производительности, которая будет в пользу С++. Кроме того, компилятор JIT может только оптимизировать сгенерированный код внутри единицы кода, JIT'ed (например, метод), в то время как компилятор С++ может оптимизировать вызовы методов с использованием более агрессивных методов.

Однако компилятор JIT может оптимизировать сгенерированный машинный код, чтобы он соответствовал базовому оборудованию, позволяющему ему использовать дополнительные аппаратные функции, если они существуют. Насколько мне известно, компилятор .NET JIT этого не делает, но, по-видимому, он сможет генерировать другой код для Atom, а не для процессоров Pentium.

Доступ к памяти

Собранная мусором архитектура может во многих случаях создавать более оптимальные шаблоны доступа к памяти, чем стандартный код на С++. Если область памяти, используемая для первого поколения, достаточно мала, может оставаться в кэше ЦП, увеличивая производительность. Если вы создаете и уничтожаете множество мелких объектов, накладные расходы на управляемую кучу могут быть меньше, чем требуется для среды выполнения С++. Опять же, это сильно зависит от приложения. Исследование Python производительности показывает, что определенное управляемое приложение Python может масштабироваться намного лучше, чем скомпилированная версия в результате более оптимальных шаблонов доступа к памяти.

Ответ 10

Основной проблемой будет не скорость, а стабильность в версиях и обновлениях Windows. Win32 в основном невосприимчив к версиям Windows, что делает его очень стабильным.

Когда серверы выведены из эксплуатации и программное обеспечение мигрирует, возникает много беспокойства вокруг чего-либо с использованием .Net и, как правило, много паники о версиях .net, но приложение Win32, созданное 10 лет назад, просто работает, как ничего не произошло.

Ответ 11

Не путайте!

• Если приложение С# написано в лучшем случае, и приложение С++ написано в лучшем случае, С++ быстрее.
  Много причин здесь о том, почему С++ быстрее, чем С# по сути, например, С# использует виртуальную машину, похожую на JVM в Java. В основном язык более высокого уровня имеет меньшую производительность (если используется в лучшем случае).

• Если вы опытный профессиональный программист на С#, как и опытный профессиональный программист на С++, разработка приложения с использованием С# намного проще и быстрее, чем С++.

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

Для выбора языка вы должны учитывать обстоятельства проекта и его предмет. Для общего бизнес-проекта вы должны использовать С#. Для проекта, требующего высокой производительности, такого как проект Video Converter или Image Processing, вы должны выбрать С++.

Обновление:

OK. Давайте сравним некоторые практические соображения о том, почему максимально возможная скорость С++ больше, чем С#. Рассмотрим хорошее написанное приложение С# и ту же версию С++:

• С# использует VM как средний уровень для выполнения приложения. У этого есть накладные расходы.
• AFAIK CLR не смог оптимизировать все коды С# на целевой машине. Приложение С++ может быть скомпилировано на целевой машине с большей оптимизацией.
• В С# наиболее возможная оптимизация для времени выполнения означает максимально возможную быструю VM. В любом случае, VM имеет накладные расходы.
• С# - язык более высокого уровня, поэтому он генерирует больше строк кода программы для окончательного процесса. (рассмотрите разницу между приложением Assembly и Ruby одним и тем же условием между С++ и языком более высокого уровня, например С#/Java).

Если вы предпочитаете получать дополнительную информацию на практике в качестве эксперта, см. это. Речь идет о Java, но она также относится к С#.

Ответ 12

Я занимаюсь оптимизацией уже около 15 лет и регулярно пишу код на С++, максимально используя возможности встроенного компилятора, поскольку производительность С++ часто нигде не приближается к тому, на что способен процессор. Часто необходимо учитывать производительность кэша. Для замены стандартного кода с плавающей запятой С++ требуется множество инструкций по векторной математике. Много кода STL написано и часто выполняется во много раз быстрее. Математика и код, который сильно использует данные, могут быть переписаны с впечатляющими результатами, так как процессор приближается к своей оптимальной производительности.

В С# это невозможно. Для сравнения их относительного # реального времени # производительность действительно является ошеломляюще невежественным вопросом. Самая быстрая часть кода на С++ будет, когда каждая отдельная инструкция ассемблера оптимизирована для задачи в руке, без каких-либо лишних инструкций - вообще. Где каждая единица памяти используется, когда она требуется, и не копируется n раз, потому что это то, что требует язык. Где каждое требуемое движение памяти работает в гармонии с кешем. Если окончательный алгоритм не может быть улучшен, исходя из точных требований реального времени, учитывая точность и функциональность.

Тогда вы будете приближаться к оптимальному решению.

Сравнивать С# с этой идеальной ситуацией является ошеломляющим. С# не может конкурировать. На самом деле, в настоящее время я пишу целую кучу кода на С# (когда я говорю, что я пишу, я имею в виду удаление и замену его полностью), потому что это даже не в том же городе, не говоря уже о парке шаров, когда дело доходит до тяжелого подъема в реальном времени производительность.

Так что, перестань обманывать себя. С# медленный. Мертвые медленно. Все программное обеспечение замедляется, а С# делает эту скорость хуже. Все программное обеспечение работает с использованием цикла выполнения выборки в ассемблере (вы знаете - на процессоре). Вы используете в 10 раз больше инструкций; он будет идти в 10 раз медленнее. Вы калечите кеш; это будет еще медленнее. Вы добавляете сбор мусора в кусок программного обеспечения в реальном времени, тогда вас часто обманывают, думая, что код работает "хорошо, есть только те несколько моментов каждый раз, когда код" немного замедляется ".

Попробуйте добавить систему сбора мусора в код, где подсчитывается каждый цикл. Интересно, имеет ли программное обеспечение для торговли на фондовом рынке сбор мусора (вы знаете - на системе, работающей на новом подводном кабеле, который стоит 300 миллионов долларов?). Можем ли мы резервировать 300 миллисекунд каждые 2 секунды? Как насчет программного обеспечения управления полетом на космическом челноке - там GC? Как насчет программного обеспечения для управления двигателем в транспортных средствах с производительностью? (Где победа в сезоне может стоить миллионы).

Сбор мусора в режиме реального времени является полным сбоем.

Нет, решительно, С++ намного быстрее. С# - прыжок назад.