Электростальский форум
Hi-Tech => Компьютеры, периферия, мультимедиа и ПО => Тема начата: exBoMBeR от 15.10.07, 09:07:11
-
Java обгоняет по производительности C++
http://www.codenet.ru/webmast/java/javavscpp.php (http://www.codenet.ru/webmast/java/javavscpp.php)
Автор: Кейт Ли, 18.06.2004
Оригинал: http://kano.net/javabench/
Одним из главных недостатков языка Java традиционно считается невысокая скорость работы программ по сравнению с приложениями на языке С++. И для приложений, где переносимость между платформами или сложность разработки не является критически важной, именно скорость часто была причиной, по которой разработчики делали выбор в пользу С++.
Однако опубликованные программистом Кейтом Ли результаты новых тестов показывают, что бытующее мнение о медленной работе Java не вполне справедливо.
Сравненние производительности Java vs. C++
Сравнению подвергались программы на С++, скомпилированные при помощи G++ (GCC) 3.3.1, и программы на Java, скомпилированные при помощи Sun Java 1.4.2_01. Для выполнения Java-программ использовалась виртуальная машина Sun версии 1.4.2_01. Измерения велисть на ноутбуке с процессором Pentium 4 и 512 Мб памяти, который работает под управлением ОС Red Hat Linux 9 / Fedora Test 1 с ядром версии 2.4.20-20.9 на .
В ходе тестирования выяснилось, что ключевым моментом, влияющим на производительность программ на Java являются настройки виртуальной машины. Как видно из диаграммы, при использовании "клиентского" варианта настроек (он установлен по умолчанию) практически все операции программы на Java выполняют медленнее, чем программы на C++, хотя и не так сильно, как можно было бы предположить. Зато при включении "серверных" настроек, в которых нет столь жестких ограничений по занимаемому объему памяти, преимущество в большинстве тестов оказалось на стороне Java. Причем ряд операций, например, вызов метода и хэширование, выполняется в программах на Java в несколько раз больше, чем в программах на C++. Впрочем, в основной массе тестов скорости Java и C++ оказались сопоставимыми, что, конечно, тоже может служить аргументом против мнения о медленной работе Java.
-
Во-первых, опять баян. Во-вторых, тесты написаны криво и все притянуто за уши, чтобы java выглядела лучше. Короче, все это инсинуация и злобная провокация.
Не смотря на это - без всяких оптмизаций:
time ./methcall 1000000000
true
false
real 0m11.305s
user 0m11.289s
sys 0m0.000s
$ time java -classpath methcall.jar methcall 1000000000
true
false
real 0m12.964s
user 0m12.886s
sys 0m0.010s
-
Во-первых, опять баян. Во-вторых, тесты написаны криво и все притянуто за уши, чтобы java выглядела лучше. Короче, все это инсинуация и злобная провокация.
Естественно ... при желании можно написать тесты, которые покажут что Shell-скрипт работает быстрее ассемблера ;--p
-
Подобных тестов было и ещё будет. Что касается кода из статьи - КГ/АМ. Виртуальные функции, двойные указатели и пр. конструкиции, используемые автором в этом C++ коде, никогда не были быстрыми. Я проводил подобные тесты на нужном мне коде и результами могу поделиться. Тут два аспекта. Есть код, который что-то считает и выводит на консольку. Назовём его счётной задачей. На таком коде жава медленнее C++ примерно на треть в засисимости от задачи и компилятра до 50%. С одной стороны, ради портабельности таким падением можно и пожертвовать. С другой стороны, сделать такой код непортабельным - это надо быть кулЬ хацкером. Люди, которые у нас делают счётные задачи на С++, никогда и не знали о проблемах переносимости. Меня это удивило в своё время. А есть код, который занимается, скажем так, вводом-выводом информации. Например, возьмём вывод графики. Крайне непортабельная вещь. Вот тут жава - реальный тормоз. Особенно, её инкарнации типа Java2ME - просто превед. Это реально уровень компьтеюров типа Спектрум. Годится разве что для менюх HD DVD. Жава - временно. До победы технологии .Net.
-
...
До победы технологии .Net.
А чем .Net принципиально отличается от Java, ктроме того что для Microsoft она своя-родная?
И там и там JIT-компилируемый байт-код. И там и там выполнение в песочнице. И там и там возможность вызова не контролируемого Native-кода ...