Кто-либо может определить количество различий в производительности между C++ и Java?
Это работает для меня.
new Thread(() =>
{
Thread.CurrentThread.IsBackground = false;
Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Background, (SendOrPostCallback)delegate {
//Your Code here.
}, null);
}).Start();
13 ответов
JIT-компиляторы могут быть быстрее для многих отдельных конструкций кода, потому что они могут использовать в своих интересах профилирование во время выполнения кода.
, Например, VonC в его ответе на этот вопрос упоминает выделение "кучи" для всех объектов. Это не на самом деле верно: JIT может выделить объекты на стеке, если это может доказать escape-анализ , что ссылки на объект не переживут стековый фрейм. Таким образом компилятор может получить выигрыш в производительности выделения стека, в то время как программист может пребывать в уверенности безопасности принятого выделения "кучи" GC.
Точно так же Uri упоминает виртуальные функции (названный виртуальными методами на большинстве языков НеC++). Это - другой случай, что JIT-компиляторы имеют преимущество, которое никогда не почти доступно загодя (AOT) компиляторам: JIT может вставить встроенную дешевую проверку типа (сравнение разыменованного слова) и на самом деле встроить виртуальный вызов метода, если тот конкретный сайт вызова, оказывается, является мономорфным (т.е. фактический тип всегда является тем же на практике). Оказывается, что [до 111], 95% всех виртуальных вызовов метода являются мономорфными на практике, таким образом, это может быть вполне большой победой - и это - победа, которая трудна для компиляторов AOT использовать в своих интересах, так как загрузка кода во время выполнения может изменить характеристики во время выполнения динамично.
Некоторые вещи более крепки с Java, C# или любыми Управляемыми языками программирования. Другие вещи будут всегда быть более крепкими с неуправляемым языком программирования (как C или C++)
, Бывшая категория обычно включает "приложения" в целом, в то время как вторая категория обычно включает "платформы" в целом.
Для создания FireFox или WebKit в Java не только что прост глупый, но заставит конечный продукт стать действительно, действительно замедлиться, плохо и потратить впустую много ресурсов для конечных пользователей. Откройте Office является, возможно, хорошим кандидатом на Java, C# или SmallTalk в этом отношении. Но создавать FireFox или WebKit в Java (или C# в этом отношении) - просто глупый и - гарантия отказа...
C++ и C будут несколькими заказами величин быстрее для многих вещей, в дополнение к которым это будет использовать часть памяти. Это - просто способ, которым это. И, пока Java и C# являются "Управляемыми" языками программирования, которые это никогда не будет изменять. Возможно, когда-нибудь центральные процессоры так быстры, что "это не имеет значения". Но я сомневаюсь относительно него, так как люди склонны сгибать свои требования, поскольку больше ЦП дано...
, Если Вы хотите создать браузер, я вынужден сказать, что необходимо преподавать себе C или C++;)
Я не полагаю, что любой может доказать, что C++ всегда будет обоснованно быстрее, чем Java для очевидного факта, что можно всегда возвращаться к JNI для получения собственной скорости от Java.
Видят, например, SWT, которые являются графическими инструментами, созданными IBM (я думаю) означали заменять Swing и давать и собственную производительность и стиль.
я, со своей стороны, предпочел бы простоту разработки по скорости, так как я полагаю, что минимальное время разработки более важно, чем необработанная скорость приложения, особенно когда я могу все еще получить ту скорость - у меня могут быть оба простота разработки Java с скорость скомпилированных языков.
Некоторые точки для принятия во внимание:
-
, Если Вы получаете лучший компилятор C++, Ваш код не становится быстрее. Необходимо перекомпилировать его сначала. Если Вы получите лучшую JVM, весь Ваш код Java будет работать быстрее
-
, Если Вы получите лучший компилятор/JVM C++, Вы будете видеть на 10-20% более быстрое выполнение, обычно в угловых случаях. Если Вы находите, что лучший алгоритм достигает того, в чем Вы нуждаетесь, можно легко добраться 1,000 производительности на %-10 000% больше, иногда еще больше.
Поэтому сегодня, если производительность является проблемой, необходимо посмотреть на эти два факта:
- , Как легкий язык добирается до замены один алгоритм с другим? (иначе "Осуществляющий рефакторинг")
- , Как быстро можно записать код в нем?
Что-либо еще - просто FUD.
То, что забывают многие люди, - то, что методы JIT могут быть применены к любому виду двоичных файлов, даже произведенные компилятором C++. Большинство преимуществ JIT-компиляции для Java также допустимо для C++ при использовании чего-то как Динамо HP (эмулятор, который выполняет исполняемые файлы быстрее, чем собственная микросхема, на которой это работает и эмулирует). Профилирование во время выполнения не является действительно преимуществом производительности Java, но JIT-компиляции в целом.
Во многих отношениях это похоже на сравнение яблок к апельсинам.
C++ основан на понятии, что Вы не оплачиваете стоимость ни за что, что Вы не используете. При управлении памятью сами если Вы не используете виртуальные функции, и т.д.
, Java не дает Вам ту свободу. Это дает Вам функции, которые Вы даже не можете хотеть. Для всего можно хотеть выделить память сами, необходимо будет использовать объекты "кучи" для всего, таким образом, Вы возьмете влияние сборки "мусора".
, Как только Вы начинаете говорить о графический интерфейсах пользователя, это - еще более трудное сравнение начиная с различных платформ UI, и инструментарии имеют различные проблемы производительности. Например, Swing/AWT обычно будет медленнее, чем что-то записанное непосредственно для собственной ОС. В C++ Вы будете редко находить действительно портативный инструментарий, и т.д.
я думаю, что, когда разработчики запустили openoffice, Java был намного медленнее, и инструментарии UI были медленными и ужасными. Инструменты как Eclipse доказывают, что можно создать относительно хороший UIs даже в Java, хотя по общему признанию, SWT является инструментарием, который делает много вещей на собственном уровне.
Для завершения ответа Мира и Uri вот [приблизительно 1 110] недавние сравнительные тесты:
- Сравнение производительности - C++ / Java / Python / Ruby / Jython / JRuby / Производительность (Википедия) Groovy
- Java
, Как сказано, те - два совсем других языка, и некоторые убеждены, что Java когда-либо будет медленнее, чем C++ из-за:
- выделение "кучи" для [1 111] весь объекты (даже маленькие как итераторы)
- партии динамических кастингов
- увеличенное использование памяти
[Юмор]
"Java является высокой производительностью. Высокой производительностью мы имеем в виду соответствующий. Соответствующим мы имеем в виду медленный". г-н Bunny
, Как упомянуто dribeas в комментариях, выделение "кучи" не является хорошим аргументом.
Этот" Городские легенды производительности, пересмотренные " упоминания:
"Сборка "мусора" никогда не будет так же эффективна как управление непосредственной памятью". И, в некотором смысле, те операторы являются правильными - , управление динамической памятью не так быстро - это часто значительно быстрее .
malloc/free приближаются к соглашениям с блоками памяти по одному, тогда как подход сборки "мусора" имеет тенденцию иметь дело с управлением памятью в больших пакетах, приводя к большему количеству возможностей для оптимизации (за счет некоторой потери в предсказуемости).
Языки не имеют скорости. Ни один, которого Java или спецификации языка C++ определяют "и программы, не должен быть скомпилирован, чтобы быть это эффективен".
Каждый язык определяет список вещей, которые программа должна сделать, или по крайней мере, , кажется, делают , которые в некоторых случаях ставят верхнюю границу, насколько эффективный программа может быть, но часто, умный компилятор может проигнорировать эти правила в отдельных программах, потому что все, что имеет значение, - то, что программа ведет себя , как будто спецификация сопровождалась. Функции могут быть встроены, данные "кучи" могут быть перемещены в стек и так далее.
производительность программы зависит от трех вещей: компилятор, базовая платформа / аппаратные средства и сам код программы.
Не "язык". Самым близким, который Вы получаете, является компилятор.
существуют серьезные основания, почему любой язык мог быть быстрее, чем другой. C++ делает меньше обещаний, которые могли потенциально замедлить выполнение программы, но Java является JIT'ed, что означает, что это могло потенциально использовать в своих интересах информацию о выполнении для оптимизации кода, который не может легко сделать C++... И с другой стороны, нигде в спецификации не делает она говорит, что C++ должен не быть jit'ed. Точно так же, как я полагаю, что существуют также компиляторы Java, которые генерируют собственный код вместо байт-кода JVM.
Ваш вопрос только имеет смысл, если у Вас есть определенный компьютер, Вы работаете, определенный компилятор для каждого языка и определенная реализация Вашей программы в каждом языке, , в этом случае Вы могли просто выполнить обоих для наблюдения, который был самым быстрым .
Сборка "мусора" является другим замечательным примером. Конечно, сборка "мусора" подразумевает немного служебные, но она также включает некоторые значительные ярлыки. Выделение "кучи" является смехотворно дешевым на управляемых языках как Java или.NET, , потому что этим управляют и собрало "мусор". В C++ это является.... неуказанным, конечно, но на практике, обычно очень медленным, потому что ОС должна пересечь "кучу" для нахождения свободного блока памяти в более или менее фрагментированном пространстве памяти. Который является самым быстрым? Зависит от ОС. Зависит от компилятора. Зависит от исходного кода.
исходный код имеет большое значение также. Если Вы возьмете программу Java и наивно портируете ее на C++, она будет работать как дерьмо. C++ не имеет дело, что хорошо с виртуальными функциями, и обычно имеет превосходящие альтернативы, доступные, Вы могли использовать вместо этого. Выделение "кучи" может быть очень медленным в C++, поэтому снова, наивно повторно реализование программы Java было бы чрезвычайно неэффективно. И то же применяется при хождении противоположным путем. Много идиом C++ были бы напрасно медленными, если портировано непосредственно к Java. Таким образом, даже если Вы обосновались на одной платформе и одном компиляторе, как Вы сравниваете производительность своей программы? Для ровного получения его к компилятору необходимо записать две реализации его, и затем это больше не та же программа.
Однако я думаю, что справедливости ради стоит отметить, что на самых современных аппаратных средствах, с современным компилятором Java и современным компилятором C++, большинство программ может быть реализовано, чтобы быть очень эффективным, и конечно достаточно быстро. Но только если Вы понимаете язык, Вы работаете с, и игра по ее правилам. При попытке записать код Java в C++, то Java волшебно окажется значительно более эффективным, и наоборот.
я предполагаю, что самый краткий ответ на Ваш вопрос "Нет. Никто не может определить количество различий в производительности между C++ и Java";)
Мне этим вопросом является определенный отвлекающий маневр (возможно, не намеренный). Действительно неправильный вопрос спросить.
первые вопросы спросить являются этими
- , Что сохраняет мою программу медленной?
- Для моей новой программы, каковы ключевые конструктивные соображения производительности?
Вот некоторая польза, 'почему' вопросами
- Является там слишком много ненужного ввода-вывода?
- слишком много используемой памяти?
- перегружаемое средство выделения памяти (слишком много выделений, слишком многие мелкомодульный объект)
- моя программа, заблокированная в сети I/O в течение многих длительных периодов
- , Действительно имеют, привязывает неправильное место
, я подозреваю, что действительно необходимо сфокусироваться на аспекты P erformance программы (с капиталом 'P') instea передозировка performance (мало 'p') аспекты сначала. Если можно перейти к сути дела, где язык находится в пути, то Вы сделали действительно хорошее задание к той точке относительно производительности.
Для нового кода - ее важное для планирования производительность и эффективность впереди. Я всегда рекомендую, чтобы производительность и эффективность рассматривали точно так же, как любая другая функция (они - функции): точно так же, как шик UI или надежность. , Конечно это будет зависеть от многих вещей - но когда его важное необходимо будет запланировать его впереди:
- структуры данных Выбора и алгоритмы, подходящие для набора данных и ожидаемого масштабирования
- Мультипоток основанные на UI приложения, где соответствующий (поток UI, поток фона/обработки)
- План относительно длинных задержек сети I/O
- План установить цели и регулярно измерять уровень впереди - выполненные регрессионные тесты
- использование памяти Меры - пожиратели ресурсов памяти являются медленными (позволяют шуткам начаться:))
- не опрашивают, когда существуют события, обратные вызовы или другие механизмы уведомления
причина, я думаю, что это - отвлекающий маневр, то, который редко делает тот, просто добираются для выбора между C++ и Java - они очень, очень различные языки с совсем другим временем выполнения. Я подозреваю, более обычно, что у Вас есть другие ограничения, продвигая Вас один путь или другой - они будут факторами высшего порядка, чем производительность языка. Исчисляемость с существующим кодом, навыками и опытом выходящего штата, и т.д. и т.д.
среда имеет значение также. Например, Java почти никогда не был бы правильным выбором для клиента висячих строк (по сравнению с сетью) приложение. С другой стороны собственный C++ почти никогда не был бы выбором для веб-приложения. (отметьте, я - парень окон - ситуация может быть очень diffretnt в *, отклоняют).
Я реализовал чувствительные к производительности приложения (физическое моделирование, финансовые модели) как на C, так и на Java. Реальность такова, что я всегда получал гораздо больший выигрыш в производительности за счет изменения алгоритмов, чем за счет настройки реализации, но реализация также имеет значение. На данный момент я считаю, что Java работает медленнее, чем C (у меня нет такого большого опыта работы с числами в C ++), но многое можно получить путем тщательной настройки, и эта настройка намного проще в Java, поскольку вы не нужно иметь дело с ошибками сегментации, двойным освобождением и т. д. C ++ занимает здесь среднее место, поскольку современные методы C ++ (интеллектуальные указатели, шаблоны, контейнеры STL) предлагают как скорость, так и относительную безопасность использования.
Приложения Java имеют накладные расходы на инициализацию, которых нет в программах C ++. При использовании JIT они не так оптимизированы на микроуровне, как программы на C ++. Кроме того, есть небольшие накладные расходы во время выполнения (сборщик мусора + косвенный вызов). В целом эти поддающиеся количественной оценке различия не имеют большого значения. Но ...
Хорошо известно, что при первом запуске Java-приложения оно должно активировать свой конденсатор потока, чтобы вернуть среду в состояние 1995 года. Это вносит небольшую задержку при запуске. Но как только это закончится, JVM будет работать примерно так же, как сопоставимая программа C ++, работающая на оборудовании с 1995 года.
Кроме того, есть небольшие накладные расходы во время выполнения (сборщик мусора + косвенный вызов). В целом эти поддающиеся количественной оценке различия не имеют большого значения. Но ...Хорошо известно, что когда приложение Java запускается впервые, оно должно активировать свой конденсатор потока, чтобы вернуть среду в состояние 1995 года. Это вносит небольшую задержку при запуске. Но как только это закончится, JVM будет работать примерно так же, как сопоставимая программа C ++, работающая на оборудовании с 1995 года.
Кроме того, есть небольшие накладные расходы во время выполнения (сборщик мусора + косвенный вызов). В целом эти поддающиеся количественной оценке различия не имеют большого значения. Но ...Хорошо известно, что когда приложение Java запускается впервые, оно должно активировать свой конденсатор потока, чтобы вернуть среду в состояние 1995 года. Это вносит небольшую задержку при запуске. Но как только это закончится, JVM будет работать примерно так же, как сопоставимая программа C ++, работающая на оборудовании с 1995 года.
Чем уступает Java по сравнению с C ++?
Отличный вопрос. Java и JVM имеют два основных недостатка, которые снижают производительность по сравнению с C ++:
Обобщения, основанные на стирании типов.
Отсутствие ценностных типов.
Первое означает, что общий код требует упаковки и распаковки, что влечет за собой огромное количество ненужного выделения и дополнительные уровни косвенного обращения, которые недружелюбны к кешу.
Последнее означает, что программист не может распаковать произвольные структуры данных, такие как комплексные числа (пары с плавающей запятой), записи хеш-таблицы (пары ключ-значение) и данные вершин.
Обе эти проблемы в совокупности делают невозможным реализацию эффективной общей хеш-таблицы в Java. В частности, .NET решила обе эти проблемы. Например, общая хеш-таблица Java может быть в 17 раз медленнее, чем словарь .NET .
Вдобавок JVM имеют очень медленные FFI по сравнению с C ++. Я слышал, что простой вызов внешней функции C из Java может занять 1000 циклов.