Явская работа времени выполнения против местного жителя К / C ++ кодекс?
Я стал все более удобным программированием на Яве, чем с C ++ или C. Я надеюсь получить смысл исполнительного хита, понесенного, используя переводчика JVM, в противоположность осуществлению того же «проекта» с рождения. Я понимаю, что там немного находится на одном уровне субъективности здесь; качество программы будет зависеть высоко от хорошего внедрения. Я интересуюсь следующими аспектами в общем смысле:
Должно быть некоторое основание для верхнего, используя переводчика. Там некоторое общее эмпирическое правило состоит в том, чтобы помнить? 10% 15%? (Я потянул эти числа из ничего), я прочитал случайный блог, заявив, что Явский кодекс почти с такой скоростью, как собственный код, но я думаю, что на это, возможно, оказали влияние.
Сборщик мусора JVM добавляет значительный наверху к работе во время выполнения? Я знаю, что приложения Какао начали использовать модель сборки мусора, и я соглашаюсь, что она делает программирование намного более простым, но в том, что стоит?
Каково верхнее из создания системных вызовов из Явы? Например, создание Гнезда возражает в противоположность API гнезда C.
Наконец, я вспоминаю чтение где-нибудь, что внедрение JVM единственное, пронизывал. Если это верно (который я скептически отношусь к), который означает, что Явские нити действительно не истинные нити? Ява пронизывает, в целом, соответствует основной обеспеченной ядром нити? JAVA-приложение извлекает выгоду таким же образом, родное применение было бы от нескольких ядер / несколько CPU?
Любой совет от разработчика, который понимает запутанность JVM и явской работы программы, очень ценился бы.Спасибо.
10 ответов
Java не является интерпретируемым языком и не была для нескольких версий. Байткод Java - это JIT'ed на лету. (Технически он все еще интерпретирует часть кода, но все, что имеет значение для производительности, получает JIT'ed)
Что касается производительности, что на Земле дает вам безумную идею, что "есть исходная точка для накладных расходов"? Нет. Никогда не было и никогда не будет. Не было и не будет C++ и Java, и не между Python и Javascript, или любыми другими двумя языками. Есть вещи, которые ваша конкретная версия JVM сделает быстрее, чем ваш конкретный компилятор C++, и вещи, которые ваш конкретный компилятор C++ сделает лучше, чем ваш конкретный JVM.
Так что "накладные расходы" вашего выбора языка полностью зависят от 1) того, что вы хотите, чтобы ваш код делал, и 2) от того, как вы пишете свой код.
Если вы возьмете Java-программу и переведете ее на Си++, то результат почти наверняка будет работать медленнее.
Если вы возьмете C++-программу и переведете ее на Java, то это тоже будет работать медленнее.
Не потому, что один язык "быстрее" другого, а потому, что оригинальная программа была написана для одного языка и хорошо работала на том же языке. И любая попытка перевести ее на другой язык потеряет это преимущество. В итоге вы получаете Java-программу в стиле Си++, которая не будет эффективно работать на JVM, или Java-программу в стиле Си++, которая также будет работать на -.
Ни в спецификации ни того, ни другого языка нет пункта, который "и результат должен быть как минимум на x% медленнее, чем на языке y". Как ваш компилятор Си++, так и JVM делают все возможное, чтобы все шло быстро.
И тогда характеристики производительности, которые вы видите сегодня, завтра могут измениться. Языки не имеют скорости.
Но чтобы ответить на ваши конкретные вопросы:
Должна быть какая-то база для накладных расходов при использовании интерпретатора. Есть ли какое-то общее эмпирическое правило, которое следует запомнить? 10% 15%? Я читал случайный блог, в котором говорилось, что Java-код почти так же быстр, как и нативный код, но, возможно, я был предвзятым.
Как говорилось выше, это зависит. Для многих обычных задач разница обычно не превышает нескольких процентов в любом случае. Для некоторых случаев использования вы увидите большую разницу (в любом случае. Оба языка имеют преимущества, когда речь заходит о производительности. Есть некоторые накладные расходы, связанные с JVM, но есть также огромные возможности оптимизации и, не в последнюю очередь, сборщик мусора)
Добавляет ли сборщик мусора JVM значительные накладные расходы к производительности во время выполнения? Я знаю, что приложения Cocoa начали использовать модель сбора мусора, и я согласен, что это делает программирование намного проще, но какой ценой?
В принципе, нет. В среднем сборщик мусора по многим причинам намного быстрее , чем ручное управление памятью:
- на управляемой куче динамическое распределение может быть сделано намного быстрее
- совместное владение может быть обработано с незначительной амортизационной стоимостью, где в родном языке вам пришлось бы использовать подсчет ссылок, что ужасно дорого
- в некоторых случаях разрушение объектов также значительно упрощается (большинство объектов Java может быть восстановлено только с помощью GC'ing блока памяти. В С++ деструкторы должны всегда выполняться, и почти у каждого объекта он есть)
Основная проблема с GC заключается в том, что хотя в среднем сборщик мусора работает лучше, вы теряете некоторый контроль над , когда берет на себя стоимость выполнения. Ручное управление памятью гарантирует, что ваш поток никогда не будет остановлен в ожидании очистки памяти. Сборщик мусора практически в любое время может принять решение о приостановке процесса и очистке памяти. Почти во всех случаях это достаточно быстро, чтобы не было проблем, но для жизненно важных вещей в реальном времени это проблема.
(Дополнительная проблема в том, что вы теряете немного выразительности. В С++ RAII используется для управления разного рода ресурсами. В Java нельзя использовать RAII. Вместо этого GC обрабатывает память за вас, а для всех остальных ресурсов, вы попали в беду, и вам приходится делать это самому с большим количеством проб/окончательных блоков. Нет причин, по которым RAII не может быть реализован на языке GC'ed, но он недоступен ни на Java, ни на C#)
Каковы накладные расходы на выполнение системных вызовов с Java? Например, создание объекта Socket в противоположность API сокета на C.
Примерно то же самое. Почему это должно быть по-другому? Конечно, Java должна вызывать соответствующие службы операционной системы и API, так что есть небольшие накладные расходы, но на самом деле это ничто, что вы скорее всего заметите.
Наконец, я вспоминаю, что читал где-то, что реализация JVM является однопоточной. Если это правда (к чему я отношусь скептически), означает ли это, что Java-потоки на самом деле не являются настоящими потоками? Относится ли вообще java-поток к базовому потоку, предоставляемому ядром? Выигрывает ли Java-приложение так же, как родное приложение от нескольких ядер / нескольких процессоров?
Java может использовать несколько потоков, да. JVM сама по себе может быть однопоточной (в том смысле, что все сервисы JVM работают в одном потоке), я не знаю об этом. Но ваше Java-приложение может использовать столько потоков, сколько ему нравится, и они привязаны к потокам ОС и будут использовать несколько ядер.
.http://www.w3sys.com/pages.meta/benchmarks.html
http://www.freewebs.com/godaves/javabench_revisited/
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Performance
http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
http://www.irrlicht3d.org/pivot/entry.php?id=446
и так далее. Дело в том, что не имеет значения. Узкие места и медленное программное обеспечение создаются разработчиками, а не языком (по крайней мере, сейчас)
.На самом деле, ВМ может выполнять множество оптимизаций во время выполнения, основываясь на информации, которая доступна только во время выполнения, а компилятор Си/Си++ не может этого сделать. Так что в большинстве случаев JVM будет как минимум так же быстр, как родная программа.
Брайан Гетц отвечает на большинство, если не на все ваши вопросы в своем докладе Towards a universal VM.
.Важно отметить, что
JIT код байтов Java скомпилирован в гораздо более оптимизированный код, специфичный для конкретного оборудования
против
C кода, скомпилированного и оптимизированного для общего оборудования, так что он не может использовать возможности, предоставляемые конкретным оборудованием
Поскольку Ваша цель очень скромна "Я надеюсь получить ощущение хита производительности..." Вы должны быть в состоянии выполнить большую ее часть, изучив программы и измерения, показанные в игре Computer Language Benchmarks .
Как Вы знаете, как на Java, так и на C++
, Вы можете посмотреть на исходный код программы и решить для себя, какие из Java-программ целесообразно сравнить с какими из C и C++ программ
, Вы можете посмотреть на дюжину различных задач и решить для себя, какие из них реализуют Ваше представление о "самых основных особенностях каждого языка"
, Вы можете посмотреть на различные подходы к многоядерности , или программы, навязанные на одно ядро
вы можете проверить, насколько запуск JVM может или может не влиять на эти измерения
Но вы должны подумать о , могут ли измерения крошечных программ правдоподобно указывать на вероятную производительность вашего приложения .
Как java, так и c# (и objective-c) не так быстро, как может быть нативный код. Но это имеет значение только в том случае, если у вас есть проблема, где вы не ограничены во времени на инжиниринг. Потому что у вас будет время разработать более качественный алгоритм с языком высокого уровня.
Итак, в основном, если вы разрабатываете устройство, в котором собираетесь строить миллион в год, или которое питается от аккумулятора, вы не используете java или c# для построения его основной функциональности. Однако, вы можете добавить интерпретатор lisp, чтобы облегчить настройку. Microsoft не собирается использовать c#, скажем, для ядра SQL-сервера, где производительность действительно имеет значение. С другой стороны, Visual Studio, где MS может рассчитывать на то, что пользователи будут иметь высококлассное оборудование, может быть использована в качестве витрины медленных, но высокопроизводительных технологий.
Пожалуйста, обратите внимание, что в настоящее время я занимаюсь большей частью своего программирования на Pharo Smalltalk, которое намного медленнее, чем java, c# или objective-c, и даже не является одним из самых быстрых Smalltalk. Производительность превосходит производительность.
Многие недооценивают исполнение java. Однажды мне тоже стало любопытно, и я написал простую программу на java, а затем эквивалент на c (не более чем выполняя какую-то операцию с циклом for и массивным массивом). Я не помню точных цифр, но я знаю, что java выбил c, когда программа на c не компилировалась ни с какими флагами оптимизации (под gcc). Как и ожидалось, c выбил вперед, когда я, наконец, скомпилировал ее с агрессивной оптимизацией. Честно говоря, это не был научный эксперимент, но он дал мне базовые знания о том, где именно стояла java.
Конечно, ява, вероятно, еще больше отстает, когда ты начинаешь делать вещи, требующие системных вызовов. Хотя, я видел скорость чтения 100 Мб/с на дисках и в сети с программами на java, работающими на скромном аппаратном обеспечении. Не уверен, что это точно говорит, но это указывает мне на то, что это достаточно хорошо для практически всего, что мне понадобится.
Что касается потоков, если ваша java-программа создает 2 потока, то у вас есть 2 реальных потоков.
Для адресации каждого из ваших пунктов:
- накладные расходы кода интерпретации намного выше, чем 10-15% (я бы догадался вдоль 3х-5х и выше). Для того, чтобы опуститься до 10-15%, необходимо использовать какую-то форму шага компиляции машинного кода (т.е. JIT). (Попробуйте запустить JVM с выключенным JIT, и вы увидите падение производительности, как рок.)
- Сборка мусора действительно оказывает влияние на производительность, но я бы сказал, что все согласны с тем, что это того стоит. Если вы можете позволить себе накладные расходы на компиляцию/интерпретацию байт-кода, вы можете позволить себе накладные расходы и на gc.
- Программирование сокетов на Java намного проще, чем на Си/Си++, если вы об этом спрашиваете. И с точки зрения производительности, накладные расходы на ввод/вывод сокетов доминируют над накладными расходами на выполнение Java.
- Большинство современных JVM имеют настоящие потоки, т.е. каждый поток Java выполняется потоком ядра, что позволяет потокам Java использовать современные многоядерные процессоры.
На это нелегко ответить. Написание C++ в стиле C возможно (даже хорошая идея), но как только вы пытаетесь сделать наследование на C, все становится некрасиво. Поэтому игнорируйте C и используйте Java -vs- C++, так как они ближе друг к другу.
Для того, чтобы понять это по-настоящему, необходимо написать два относительно больших приложения одинаковым образом на обоих языках. Если Вы это сделаете, то будете ли Вы использовать STL и классы из коллекции Java или напишете свои собственные и портируете их между языками? Если вы используете родной язык, то это зависит от того, какая реализация быстрее, где, как если бы вы использовали свой собственный, вы не тестируете реальную скорость работы приложения.
Я бы сказал, что вам нужно написать приложение как можно более похожее, но использовать библиотеки/идиомы, специфичные для языка, где это имеет смысл. С++ и Java код, будучи похожим, имеют разные способы работы - то, что легко на Java, может быть ужасно сложно на Си++ и наоборот.
Современная реализация GC не добавляет много накладных расходов, и вы можете переключиться на GC в C++ для сравнения, если вам нравится :-)
Есть некоторые вещи, которые может сделать Java runtime, что обычно не делается в компиляторах C++, такие как возможность встраивания виртуальных методов.
Для системного типа вещей Java обычно прибегает к вызовам на C, так что там есть накладные расходы (хотя JNI быстрее, чем раньше).
Потоки зависят от реализации. Раньше Sun использовала "зеленые потоки; для Solaris, но это уже давно прошло. Насколько я знаю больше всего (всех?) современных ВМ используют "родные" потоки.
Короче говоря, я не думаю, что существует хорошая метрика по % накладных расходов для Java -vs- C++, и любой, который вы найдете, скорее всего, будет микро-тестированием, не представляющим реальный мир (к сожалению).