Производительность C++ по сравнению с Java / C#

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

Однако вероятность того, что это действительно произойдет, довольно низка - если, возможно, у Java нет очень хорошо написанной библиотеки, а у вас есть собственная плохо написанная библиотека C++.

Как правило, C# и Java могут быть такими же быстрыми или быстрее, потому что JIT-компилятор - компилятор, который компилирует ваш IL при первом запуске - может выполнять оптимизацию, которую не может выполнить скомпилированная программа C++, потому что она может запрашивать машину. Он может определить, является ли машина Intel или AMD; Pentium 4, Core Solo или Core Duo; или если поддерживает SSE4 и т. д.

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

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

Кроме того, Java и C# могут выполнять распределение кучи более эффективно, чем C++, потому что уровень абстракции между сборщиком мусора и вашим кодом позволяет ему выполнять все сжатие кучи сразу (довольно дорогостоящая операция).

Сейчас я не могу говорить от имени Java по этому следующему пункту, но я знаю, что, например, C# фактически удалит методы и вызовы методов, когда узнает, что тело метода пусто. И он будет использовать такую ​​логику во всем вашем коде.

Итак, как видите, есть множество причин, по которым определенные реализации C# или Java будут быстрее.

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

Так что в зависимости от того, что вы пишете, я бы выбрал одно или другое. Но если вы пишете что-то, что не зависит от оборудования (драйвер, видеоигра и т. д.), Я бы не стал беспокоиться о производительности C# (опять же, не могу говорить о Java). Это будет нормально.

Со стороны Java @Swati указывает на хорошую статью:

https://www.ibm.com/developerworks/library/j-jtp09275

Исполняемый код, созданный компилятором Java или C#, не интерпретируется - он компилируется в собственный код «точно в срок» (JIT). Таким образом, первый раз, когда код в программе Java / C# встречается во время выполнения, возникают некоторые накладные расходы, поскольку «компилятор времени выполнения» (он же JIT-компилятор) превращает байтовый код (Java) или код IL (C#) в машинные инструкции машинного кода. Однако в следующий раз, когда этот код будет встречен во время работы приложения, собственный код будет выполнен немедленно. Это объясняет, почему некоторые программы Java / C# сначала кажутся медленными, но затем работают лучше, чем дольше они работают. Хорошим примером является веб-сайт ASP.Net. Самый первый доступ к веб-сайту может быть немного медленнее, поскольку код C# компилируется в собственный код JIT-компилятором. Последующие обращения приводят к гораздо более быстрому веб-сайту - не считая кеширования на стороне сервера и клиента.

Помимо того, что говорили некоторые другие, насколько я понимаю, .NET и Java лучше выделяют память. Например. они могут сжимать память, поскольку она фрагментируется, в то время как C++ не может (изначально, но может, если вы используете умный сборщик мусора).

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

1 / Среда выполнения Java обычно способна обнаруживать части кода, которые часто выполняются, и выполнять JIT-компиляцию этих разделов, чтобы в будущем они выполнялись на полной скорости компиляции.

2 / Обширные части библиотек Java скомпилированы так, что, когда вы вызываете библиотечную функцию, вы выполняете скомпилированный код, а не интерпретируете. Вы можете увидеть код (на C), загрузив OpenJDK.

3 / Если вы не выполняете массовые вычисления, большую часть времени ваша программа работает, она ожидает ввода от очень медленного (условно говоря) человека.

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

5 / В худшем случае требовательный к производительности код может быть извлечен в скомпилированный модуль и вызван из Java (см. JNI), чтобы он работал на полной скорости.

Таким образом, байт-код Java никогда не превзойдет родной машинный язык, но есть способы смягчить это. Большим преимуществом Java (как мне кажется) является стандартная библиотека ОГРОМНЫЙ и кроссплатформенность.

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

Считайте скомпилированный код Java интерпретируемым машинным языком для JVM. Когда процессор Hotspot замечает, что определенные части скомпилированного кода будут использоваться много раз, он выполняет оптимизацию машинного кода. Поскольку ручная настройка Assembly почти всегда быстрее, чем код, скомпилированный на C++, можно предположить, что программно настроенный машинный код не будет плохим тоже.

Итак, для очень повторяющегося кода я мог видеть, где JVM Hotspot могла бы запускать Java быстрее, чем C++ ... до тех пор, пока не вступит в игру сборка мусора. :)

JIT (Just In Time Compiling) может быть невероятно быстрым, потому что он оптимизируется для целевой платформы.

Это означает, что он может использовать любую уловку компилятора, которую поддерживает ваш ЦП, независимо от того, на каком ЦП разработчик написал код.

Базовая концепция .NET JIT работает следующим образом (сильно упрощенная):

Первый вызов метода:

• Ваш программный код вызывает метод Foo ()
• CLR смотрит на тип, реализующий Foo (), и получает связанные с ним метаданные.
• Из метаданных CLR знает, в каком адресе памяти хранится промежуточный байтовый код (IL).
• CLR выделяет блок памяти и вызывает JIT.
• JIT компилирует IL в машинный код, помещает его в выделенную память, а затем изменяет указатель функции в метаданных типа Foo (), чтобы он указывал на этот машинный код.
• Собственный код запущен.

Вызов метода второй раз:

• Ваш программный код вызывает метод Foo ()
• CLR проверяет тип, реализующий Foo (), и находит указатель на функцию в метаданных.
• Собственный код в этом месте памяти запускается.

Как видите, второй раз это практически тот же процесс, что и в C++, за исключением оптимизации в реальном времени.

Тем не менее, есть и другие накладные расходы, которые замедляют управляемый язык, но JIT очень помогает.

В некоторых случаях управляемый код может фактически быть Быстрее, чем собственный код. Например, алгоритмы сборки мусора «отметка и очистка» позволяют средам, подобным JRE или CLR, освобождать большое количество недолговечных (обычно) объектов за один проход, при этом большинство объектов кучи C / C++ освобождаются по очереди. время.

От википедия:

For many practical purposes, allocation/deallocation-intensive algorithms implemented in garbage collected languages can actually be faster than their equivalents using manual heap allocation. A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion.

Тем не менее, я написал много C# и много C++, и я провел много тестов. По моему опыту, C++ намного быстрее, чем C#, двумя способами: (1) если вы берете код, написанный на C#, переносите его на C++, чтобы быть быстрее, собственный код имеет тенденцию. Насколько быстрее? Что ж, он сильно различается, но нередко можно увидеть улучшение скорости на 100%. (2) В некоторых случаях сборка мусора может замедлить работу управляемого приложения с помощью массово. .NET CLR ужасно справляется с большими кучами (скажем,> 2 ГБ) и может в конечном итоге проводить много времени в сборке мусора - даже в приложениях, которые имеют мало - или даже не имеют - объектов с промежуточной продолжительностью жизни.

Конечно, в большинстве случаев, которые я описал, управляемые языки достаточно быстры, по большому счету, и компромисс между обслуживанием и кодированием для дополнительной производительности C++ просто неуместен.

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

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

Кроме того, C++ догоняет «новые» (обратите внимание на кавычки) функции, такие как контейнеры STL, автоматические указатели и т. д. - см., Например, библиотеку boost. И иногда вы можете обнаружить, что самый быстрый способ выполнить какую-либо задачу требует такой техники, как арифметика указателей, которая запрещена на языке более высокого уровня, хотя обычно они позволяют вам обращаться к библиотеке, написанной на языке, который может реализовать ее по желанию. .

Главное - знать, какой язык вы используете, связанный с ним API, что он может делать и каковы его ограничения.

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

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

• Ручное управление памятью трудно сделать правильно (без утечек), а еще труднее сделать эффективно (освободите память вскоре после того, как вы закончите с ней). Использование GC, как правило, с большей вероятностью приведет к созданию программы, которая хорошо управляет памятью. Готовы ли вы очень усердно работать и откладывать выпуск своего программного обеспечения, пытаясь превзойти сборщик мусора?

• Мой C# легче читать и понимать, чем мой C++. У меня также есть другие способы убедить себя, что мой код на C# работает правильно. Это означает, что я могу оптимизировать свои алгоритмы с меньшим риском появления ошибок (а пользователям не нравится программное обеспечение, которое дает сбой, даже если оно делает это быстро!)

• Я могу создавать свои программы на C# быстрее, чем на C++. Это освобождает время для работы над производительностью и по-прежнему доставляет мое программное обеспечение вовремя.

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

Все, что я сказал о C#, вероятно, верно и для Java, просто у меня нет опыта, чтобы сказать наверняка.

Мне нравится ответ Орион Адриан, но есть еще один аспект.

Тот же вопрос был задан несколько десятилетий назад относительно языка ассемблера и «человеческих» языков, таких как FORTRAN. И часть ответа похожа.

Да, программа на C++ способна быть быстрее, чем C#, по любому заданному (нетривиальному?) Алгоритму, но программа на C# часто будет так же быстро или быстрее, чем «наивная» реализация на C++ и оптимизированная версия на C++. на разработку уйдет больше времени, и он все равно может превзойти версию C# с очень небольшим отрывом. Так действительно ли оно того стоит?

Вам придется отвечать на этот вопрос один за другим.

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

Самый большой штраф, который вы платите? Многие программы .NET и Java занимают много памяти. Я видел, как приложения .NET и Java занимают «сотни» мегабайт памяти, тогда как программы на C++ аналогичной сложности едва занимают «десятки» мегабайт.

Если вы программист на Java / C# и изучаете C++, у вас возникнет соблазн продолжить мыслить терминами Java / C# и дословно перевести синтаксис C++. В этом случае вы получаете только ранее упомянутые преимущества нативного кода по сравнению с интерпретируемым / JIT. Чтобы получить наибольший прирост производительности в C++ по сравнению с Java / C#, вам нужно научиться думать на C++ и разрабатывать код специально, чтобы использовать сильные стороны C++.

Перефразируя Эдсгер Дейкстра: [ваш первый язык] калечит разум безвозвратно.
Перефразируя Джефф Этвуд: вы можете писать [ваш первый язык] на любом новом языке.

Компиляция для конкретных оптимизаций ЦП обычно переоценивается. Просто возьмите программу на C++, скомпилируйте с оптимизацией для Pentium PRO и запустите на Pentium 4. Затем перекомпилируйте с optimize для Pentium 4. Я провел долгие дни, делая это с несколькими программами. Общие результаты ?? Обычно прирост производительности менее 2-3%. Таким образом, теоретических преимуществ JIT практически нет. Большинство различий в производительности можно наблюдать только при использовании функций обработки скалярных данных, что в конечном итоге потребует точной настройки вручную для достижения максимальной производительности. Такого рода оптимизации медленные и дорогостоящие, что делает их в любом случае непригодными для JIT.

В реальном мире и реальных приложениях C++ по-прежнему обычно быстрее, чем java, в основном из-за меньшего объема памяти, что приводит к лучшей производительности кеша.

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

Вот интересный тест http://zi.fi/shootout/

Всякий раз, когда я говорю об управляемой и неуправляемой производительности, я хотел бы указать на серию, в которой Рико (и Раймонд) сравнивали версии китайско-английского словаря на C++ и C#. Этот поиск Гугл позволит вам прочитать сам, но мне нравится резюме Рико.

So am I ashamed by my crushing defeat? Hardly. The managed code got a very good result for hardly any effort. To defeat the managed Raymond had to:

• Write his own file I/O stuff
• Write his own string class
• Write his own allocator
• Write his own international mapping

Of course he used available lower level libraries to do this, but that's still a lot of work. Can you call what's left an STL program? I don't think so, I think he kept the std::vector class which ultimately was never a problem and he kept the find function. Pretty much everything else is gone.

So, yup, you can definately beat the CLR. Raymond can make his program go even faster I think.

Interestingly, the time to parse the file as reported by both programs internal timers is about the same -- 30ms for each. The difference is in the overhead.

Для меня суть в том, что неуправляемой версии потребовалось 6 ревизий, чтобы превзойти управляемую версию, которая была простым портом исходного неуправляемого кода. Если вам нужен каждый последний бит производительности (и у вас есть время и опыт, чтобы получить его), вам придется отказаться от управления, но для меня я воспользуюсь преимуществом на порядок, которое у меня есть в первых версиях над 33 % Я получаю, если попробую 6 раз.

На самом деле C# не работает на виртуальной машине, как Java. IL компилируется в язык ассемблера, который представляет собой полностью собственный код и работает с той же скоростью, что и собственный код. Вы можете предварительно выполнить JIT-приложение .NET, которое полностью устранит затраты на JIT, и тогда вы будете запускать полностью собственный код.

Замедление с .NET произойдет не потому, что код .NET работает медленнее, а потому, что он делает гораздо больше за кулисами, чтобы делать такие вещи, как сбор мусора, проверка ссылок, сохранение полных кадров стека и т. д. Это может быть довольно мощным и полезным, когда создание приложений, но также требует затрат. Обратите внимание, что вы можете делать все это и в программе на C++ (большая часть основных функций .NET на самом деле является кодом .NET, который вы можете просматривать в ROTOR). Однако, если вы вручную написали те же функции, вы, вероятно, в конечном итоге получили бы гораздо более медленную программу, поскольку среда выполнения .NET была оптимизирована и точно настроена.

Тем не менее, одна из сильных сторон управляемого кода состоит в том, что он может быть полностью проверяемым, т. Е. вы можете убедиться, что код никогда не будет обращаться к памяти других процессов или делать что-то неадекватное, прежде чем вы его выполните. У Microsoft есть исследовательский прототип полностью управляемой операционной системы, который неожиданно показал, что 100% управляемая среда на самом деле может работать значительно быстрее, чем любая современная операционная система, за счет использования этой проверки для отключения функций безопасности, которые больше не нужны управляемым программам. (в некоторых случаях мы говорим как 10x). У SE Radio есть отличный эпизод, рассказывающий об этом проекте.

Я тоже не знаю ... мои программы на Java всегда медленные. :-) Я никогда особо не замечал, чтобы программы на C# были особенно медленными.

На самом деле JVM Sun HotSpot использует "смешанный режим" выполнения. Он интерпретирует байт-код метода до тех пор, пока не определит (обычно через какой-либо счетчик), что конкретный блок кода (метод, цикл, блок try-catch и т. д.) Будет выполняться много раз, а затем JIT компилирует его. Время, необходимое для JIT-компиляции метода, часто занимает больше времени, чем если бы метод должен был быть интерпретирован, если это редко запускаемый метод. Производительность обычно выше для «смешанного режима», потому что JVM не тратит время на JIT-код, который запускается редко, если вообще запускается. C# и .NET этого не делают. .NET JIT выполняет все, что часто тратит время зря.

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

Стандартное выделение памяти в Java / C# также происходит быстрее, а освобождение памяти (GC) не намного медленнее, но менее детерминировано.

Вот еще один интересный тест, который вы можете попробовать на собственном компьютере.

Он сравнивает ASM, VC++, C#, Silverlight, Java-апплет, Javascript, Flash (AS3).

Демонстрация скорости плагина Roozz

Обратите внимание, что скорость javascript сильно зависит от того, какой браузер его запускает. То же самое верно для Flash и Silverlight, потому что эти плагины работают в том же процессе, что и хост-браузер. Но плагин Roozz запускает стандартные файлы .exe, которые запускаются в собственном процессе, поэтому браузер хоста не влияет на скорость.

Вот ответ от Cliff Click: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain

Вы должны определить «работать лучше, чем ..». Я знаю, вы спрашивали о скорости, но это не все, что имеет значение.

• Производят ли виртуальные машины больше накладных расходов во время выполнения? Да!
• У них больше рабочей памяти кушают? Да!
• У них более высокие затраты на запуск (инициализация среды выполнения и JIT-компилятор)? Да!
• Они требуют установки огромной библиотеки? Да!

И так далее, предвзято, да;)

С C# и Java вы платите цену за то, что получаете (более быстрое кодирование, автоматическое управление памятью, большая библиотека и т. д.). Но по мелочам торговаться особо некуда: бери весь пакет или ничего.

Даже если эти языки могут оптимизировать некоторый код для выполнения быстрее, чем скомпилированный код, весь подход (IMHO) неэффективен. Представьте себе, что вы каждый день проезжаете 5 миль до рабочего места на грузовике! Это удобно, приятно, вы в безопасности (крайняя зона деформации), а после того, как вы нажмете на газ в течение некоторого времени, он будет даже таким же быстрым, как стандартный автомобиль! Почему у всех нас нет грузовика, чтобы ехать на работу? ;)

В C++ вы получаете то, за что платите, не больше и не меньше.

Цитата Бьярна Страуструпа: «C++ - мой любимый язык со сборкой мусора, потому что он генерирует так мало мусора» текст ссылки

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

Если вы просто используете библиотеки C++ и множество его высокоуровневых функций в большом проекте со множеством классов, вы, вероятно, закончите работу медленнее, чем при использовании JVM. За исключением гораздо большего количества ошибок.

Однако преимущество C++ заключается в том, что он позволяет вам оптимизировать себя, иначе вы застрянете на том, что делает compiler / jvm. Если вы создаете свои собственные контейнеры, пишете собственное управление памятью, которое выровнено, используете SIMD и переходите к сборке здесь и там, вы можете ускорить, по крайней мере, в 2-4 раза по сравнению с тем, что большинство компиляторов C++ сделают самостоятельно. Для некоторых операций 16x-32x. Это с использованием тех же алгоритмов, если вы используете лучшие алгоритмы и распараллеливаете, увеличение может быть значительным, иногда в тысячи раз быстрее, чем обычно используемые методы.

Я смотрю на это с нескольких разных точек зрения.

1. Будет ли управляемый или неуправляемый код работать быстрее, учитывая бесконечное время и ресурсы? Ясно, что ответ заключается в том, что неуправляемый код всегда может, по крайней мере, связать управляемый код в этом аспекте - поскольку в худшем случае вы просто жестко запрограммируете решение с управляемым кодом.
2. Если вы возьмете программу на одном языке и напрямую переведете ее на другой, насколько хуже она будет работать? Наверное много, для Любые два языка. Большинство языков требуют разных оптимизаций и имеют разные подводные камни. Микропроизводительность часто зависит от знания этих деталей.
3. При ограниченном времени и ресурсах, какой из двух языков даст лучший результат? Это наиболее интересный вопрос, поскольку, хотя управляемый язык может производить немного более медленный код (при условии, что программа разумно написана для этого языка), эта версия, вероятно, будет создана раньше, что позволит потратить больше времени на оптимизацию.

Очень короткий ответ: при фиксированном бюджете вы добьетесь более высокой производительности Java-приложения, чем приложение C++ (соображения рентабельности инвестиций). Кроме того, платформа Java имеет более достойные профилировщики, которые помогут вам быстрее определять ваши горячие точки.

Прочтите о Динамо HP Labs, интерпретаторе для PA-8000, который работает на PA-8000 и часто запускает программы быстрее, чем изначально. Тогда это совсем не покажется удивительным!

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

Часто это сводится к:

• у программ есть горячие точки, поэтому даже если вы медленнее выполняете 95% кода, который вам нужно запустить, вы все равно можете быть конкурентоспособными по производительности, если вы быстрее на горячих 5%

• HLL знает о ваших намерениях больше, чем LLL, такой как C / C++, и поэтому может генерировать более оптимизированный код (OCaml имеет даже больше, а на практике часто даже быстрее)

• JIT-компилятор имеет много информации, которой нет у статического компилятора (например, фактические данные, которые у вас есть на этот раз)

• JIT-компилятор может выполнять оптимизацию во время выполнения, которую традиционным компоновщикам на самом деле не разрешено делать (например, переупорядочивание ветвей, чтобы общий случай был плоским, или встраивание вызовов библиотеки)

В общем, C / C++ - довольно плохие языки для производительности: относительно мало информации о ваших типах данных, нет информации о ваших данных и нет динамической среды выполнения, которая позволяла бы многое оптимизировать во время выполнения.

Вы можете получить короткие всплески, когда Java или CLR быстрее, чем C++, но в целом производительность будет хуже в течение всего срока службы приложения: см. www.codeproject.com/KB/dotnet/RuntimePerformance.aspx для получения некоторых результатов по этому поводу.

My understanding is that C/C++ produces native code to run on a particular machine architecture. Conversely, languages like Java and C# run on top of a virtual machine which abstracts away the native architecture. Logically it would seem impossible for Java or C# to match the speed of C++ because of this intermediate step, however I've been told that the latest compilers ("hot spot") can attain this speed or even exceed it.

Это нелогично. Использование промежуточного представления по своей сути не снижает производительность. Например, llvm-gcc компилирует C и C++ через LLVM IR (который представляет собой виртуальную машину с бесконечным числом регистров) в собственный код и обеспечивает отличную производительность (часто превосходящую GCC).

Perhaps this is more of a compiler question than a language question, but can anyone explain in plain English how it is possible for one of these virtual machine languages to perform better than a native language?

Вот некоторые примеры:

• Виртуальные машины с JIT-компиляцией облегчают генерацию кода времени выполнения (например, System.Reflection.Emit в .NET), поэтому вы можете компилировать сгенерированный код на лету на таких языках, как C# и F#, но должны прибегать к написанию сравнительно медленного интерпретатора на C или C++. Например, для реализации регулярных выражений.

• Части виртуальной машины (например, барьер записи и распределитель) часто пишутся на ассемблере, написанном вручную, потому что C и C++ не генерируют достаточно быстрый код. Если программа нагружает эти части системы, она может превзойти все, что может быть написано на C или C++.

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

Я также хотел бы затронуть некоторые проблемы с высоко оцененным ответом paercebal выше (потому что кто-то продолжает удалять мои комментарии к его ответу), который представляет контрпродуктивно поляризованное мнение:

The code processing will be done at compilation time...

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

...playing with types is done at compile time...the equivalent in Java or C# is painful at best to write, and will always be slower and resolved at runtime even when the types are known at compile time.

В C# это верно только для ссылочных типов и неверно для типов значений.

No matter the JIT optimization, nothing will go has fast as direct pointer access to memory...if you have contiguous data in memory, accessing it through C++ pointers (i.e. C pointers... Let's give Caesar its due) will goes times faster than in Java/C#.

Люди наблюдали Java превосходит C++ в тесте SOR из теста SciMark2 именно потому, что указатели препятствуют оптимизации, связанной с псевдонимом.

Также стоит отметить, что .NET выполняет специализацию типов для универсальных библиотек после связывания, тогда как C++ не может этого сделать, потому что шаблоны должны быть разрешены перед связыванием. И, очевидно, большое преимущество дженериков перед шаблонами - это понятные сообщения об ошибках.

Я не думаю, что в наши дни производительность нужно учитывать по отношению к скорости обработки сервера (в конце концов, многоядерные процессоры появились на рынке). Он должен быть более определен в зависимости от использования памяти. И в этом случае у java есть небольшой недостаток.
Но все же в целом языки программирования подходят для разных целей. И это их конкурентное поле, на каждом участке разные победители. И я уверен, что Java выиграет в долгосрочной перспективе, поскольку она продолжает развиваться и конкурентоспособность, которую демонстрирует во всех новых функциях, которые она создает. Я нашел здесь связь, который подтвердит мою причину голосования за java