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

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

На самом деле HotSpot JVM Sun использует выполнение "смешанного режима". Это интерпретирует байт-код метода, пока это не определяет (обычно через какой-то счетчик), что конкретный блок кода (метод, цикл, блок try-catch, и т.д.) будет выполняемым много, затем это, JIT компилирует его. Время, требуемое к JIT, компилирует метод, часто занимает больше времени, чем если бы метод должен был быть интерпретирован, если это - редко выполняемый метод. Производительность обычно выше для "смешанного режима", потому что JVM не напрасно тратит время код JITing, который редко является, если когда-либо, выполнение. C# и.NET не делают этого. МОНЕТЫ В ПЯТЬ ЦЕНТОВ.NET все, что, часто времена, напрасно тратит время.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

фундаментальное понятие JIT.NET работает как это (в большой степени упрощенный):

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

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

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

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

, Как Вы видите, в 2-й раз вокруг, фактически тот же процесс как C++, кроме с преимуществом оперативной оптимизации.

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

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

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

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

Каждый раз, когда я говорю управляемый по сравнению с неуправляемой производительностью, мне нравится указывать на ряд на Rico (и Raymond) сделал сравнение C++ и версий C# китайского/Английского словаря. Этот поиск Google позволит Вам читать для себя, но мне нравится сводка Rico.

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

• Запись его собственный материал файлового ввода-вывода
• Запись его собственная Запись строкового класса
• его собственное средство выделения
• Запись его собственное международное отображение

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

Так, да, можно определенно победить CLR. Raymond может заставить свою программу пойти еще быстрее, я думаю.

Интересно, время для парсинга файла, как сообщается обеими программами внутренние таймеры о том же - 30 мс для каждого. Различие находится в издержках.

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

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

Мне нравится Orion Adrian ответ, но существует другой аспект к нему.

тот же вопрос был несколько изложенных десятилетия назад об ассемблере по сравнению с "человеческими" языками как ФОРТРАН. И часть ответа подобна.

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

необходимо будет ответить на тот вопрос на один за другим основание.

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

самый большой штраф Вы платите? Многие.NET и программы Java являются пожирателями ресурсов памяти. Я видел.NET, и приложения Java берут "сотни" мегабайтов памяти, когда программы C++ подобной сложности едва царапают "десятки" MBS.

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

Некоторые хорошие ответы здесь о конкретном вопросе Вы спросили. Я хотел бы отступить и посмотреть на большее изображение.

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

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

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

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

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

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

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

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

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

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

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

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

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

Для перефразирования Edsger Dijkstra : [Ваш первый язык] калечит ум вне восстановления.
Для перефразирования Jeff Atwood : можно записать [первый язык] на любом новом языке.

JIT по сравнению со статическим компилятором

Как уже сказано в предыдущих сообщениях, JIT может скомпилировать IL/bytecode в собственный код во времени выполнения. Стоимость этого была упомянута, но не к ее заключению:

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

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

Метапрограммирование C++

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

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

Редактирование 10.06.2011: В C++, играющем с типами, сделан во время компиляции, означая производящий общий код, который называет необщий код (например, универсальный синтаксический анализатор от строки до типа T, называние стандартной библиотеки API для типов T это распознает, и создание синтаксического анализатора, легко расширяемого его пользователем), очень легко и очень эффективен, тогда как эквивалент в Java или C# является болезненным в лучшем случае для записи, и всегда будет медленнее и разрешен во времени выполнения, даже когда типы известны во время компиляции, означая, что единственная надежда состоит в том, чтобы JIT встроил все это.

...

Редактирование 20.09.2011: команда позади Блица ++ (Домашняя страница, Википедия) пошла тем путем, и по-видимому, их цель состоит в том, чтобы достигнуть производительности ФОРТРАНА на научных вычислениях путем перемещения как можно больше от выполнения во время выполнения до времени компиляции через шаблонное метапрограммирование C++. Так "Я имею все же, так посмотрите, что реальный эффект на эту" первую часть записал выше, по-видимому, существует в реальной жизни.

Собственное использование памяти C++

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

Неважно, оптимизация JIT, ничто не пойдет, имеет быстро как прямой доступ указателя к памяти (давайте проигнорируем на мгновение кэши процессора, и т.д.). Так, если у Вас есть непрерывные данные в памяти, получая доступ к нему через указатели C++ (т.е. указатели C... Давайте дадим Caesar его должное), будет идти времена быстрее, чем в Java/C#. И C++ имеет RAII, который делает большую обработку намного легче, чем в C# или даже в Java. C++ не нужно using определять объем существования его объектов. И C++ не имеет a finally пункт. Это не ошибка.

:-)

И несмотря на подобные примитиву структуры C#, C++ "на стеке" объекты ничего не будет стоить при выделении и разрушении, и не будет нуждаться ни в каком GC для работы в независимом потоке, чтобы сделать очистку.

Что касается фрагментации памяти, средства выделения памяти в 2008 не являются старыми средствами выделения памяти с 1980, которые обычно являются по сравнению с GC: выделение C++ не может быть перемещено в память, верную, но затем, как в файловой системе Linux: Кому нужна дефрагментация жесткого диска, когда фрагментации не происходит? Используя правильное средство выделения для правильной задачи должна быть часть инструментария разработчика C++. Теперь, запись средств выделения не легка, и затем, у большинства из нас есть лучшие вещи сделать, и для большей части использования, RAII или GC более, чем достаточно хороши.

Редактирование 04.10.2011: Для примеров об эффективных средствах выделения: На платформах Windows, начиная с Vista, Слабо фрагментируемая "куча" включена по умолчанию. Для предыдущих версий LFH может быть активирован путем вызывания функции WinAPI HeapSetInformation). На других Ose обеспечиваются альтернативные средства выделения (см. https://secure.wikimedia.org/wikipedia/en/wiki/Malloc для списка),

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

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

C++ / CLI по сравнению с C#/VB.NET

Примечание: В этом разделе я говорю о C++ / CLI, то есть, C++, размещенный.NET, не собственным C++.

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

Тот же самый код, скомпилированный в C++ / CLI (или его предок, Управляемый С++), мог быть временами быстрее, чем тот же код, произведенный в C# (или VB.NET, компилятор которого производит тот же IL, чем C#).

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

Например, встраивание функции в.NET ограничено функциями, байт-код которых меньше или равен, чем 32 байта в длине. Так, некоторый код в C# произведет 40-байтовое средство доступа, которое никогда не будет встраиваться JIT. Тот же код в C++ / CLI произведет 20-байтовое средство доступа, которое будет встроено JIT.

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

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

Заключение

Я люблю C++.

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

Редактирование (2011-06-06)

Мой опыт в C#/.NET

У меня есть теперь 5 месяцев почти эксклюзивного профессионального кодирования C# (который составляет в целом мой CV, уже полный C++ и Java и легкого C++ / CLI).

Я играл с WinForms (Гм...) и WCF (прохладный!), и WPF (Прохладный!!!! И через XAML и через необработанный C#. WPF так легок, я полагаю, что Swing просто не может выдержать сравнение с ним), и C# 4.0.

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

1. Дженерики не так мощны как шаблоны (попытайтесь записать эффективный универсальный метод Синтаксического анализа (от строки до T), или эффективный эквивалент повышения:: lexical_cast в C# для понимания проблемы)
2. RAII остается несопоставленным (GC все еще может протечь (да, я должен был решить ту проблему), и только обработает память. Даже C# using не так легко и мощен, потому что запись корректного Располагает реализации, является трудным),
3. C# readonly и Java final нигде не так полезны как C++ const (Нет никакого способа, которым можно выставить сложные данные только для чтения (Дерево Узлов, например) в C# без огромной работы, в то время как это - встроенная функция C++. Неизменные данные являются интересным решением, но не все может быть сделан неизменным, таким образом, это даже не достаточно, безусловно).

Так, C# остается приятным языком, пока Вы хотите что-то, что работает, но расстраивающий язык момент, Вы хотите что-то, что всегда и безопасно работает.

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

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

О Java серверной стороны и C++

Я поддерживал контакт с командами сервера (я работал 2 года среди них перед возвращением к команде GUI), в другой стороне здания, и я изучил что-то интересное.

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

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

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

Заключение

Ничто не так просто как ожидалось.

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

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

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

Конечно, это - мое собственное восприятие, возможно, ограниченное нашими определенными потребностями.

Но тем не менее, это - то, что происходит сегодня, и в командах GUI и в командах серверной стороны.

Конечно, я обновлю это сообщение, если что-то новое произойдет.

Редактирование (2011-06-22)

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

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

Источники:

• https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
• http://www.computing.co.uk/ctg/news/2076322/-winner-google-language-tests

Редактирование (2011-09-20)

"Идущее слово в Facebook - то, что 'обоснованно написанный код C++ просто работает быстро', который подчеркивает огромное усилие, потраченное при оптимизации код Java и PHP. Как это ни парадоксально код C++ более трудно написать, чем на других языках, но эффективный код намного легче [для записи в C++, чем на других языках]".

– Herb Sutter в//создает/, заключая Andrei Alexandrescu в кавычки

Источники:

• http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T
• http://video.ch9.ms/build/2011/slides/TOOL-835T_Sutter.pptx

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

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

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

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

Вот ответ Клиффа Клик: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain

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

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

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

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

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

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

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

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

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

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

I look at it from a few different points.

1. Given infinite time and resources, will managed or unmanaged code be faster? Clearly, the answer is that unmanaged code can always at least tie managed code in this aspect - as in the worst case, you'd just hard-code the managed code solution.
2. If you take a program in one language, and directly translate it to another, how much worse will it perform? Probably a lot, for any two languages. Most languages require different optimizations and have different gotchas. Micro-performance is often a lot about knowing these details.
3. Given finite time and resources, which of two languages will produce a better result? This is the most interesting question, as while a managed language may produce slightly slower code (given a program reasonably written for that language), that version will likely be done sooner, allowing for more time spent on optimization.

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

Прочитайте о HP Labs Dynamo , интерпретаторе для 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 для получения некоторых результатов.