14 апреля 2009, 18:22:49

Что за дауны отвечали в каментариях... какой интерпретатор ещё? что выполняется виртуальной машиной? хоть бы википедию почитали для начала, прежде чем предположения авторитетно делать.

15 ноября 2007, 14:24:23

А вот и объяснение "супер скорости Java'ы"
http://www.w3sys.com/pages.meta/benchmarks.html

17 августа 2007, 17:07:11

Полнейшая ерунда не видел ни когда быстрой программы на Java, как серверной так и клиентской.

2Знатокам. Oracle10g написан на сях как минимум, а вот в негу уже в свою очереть интегрираванна Java машина вот и получилось что то вроде Oracle Aplication Server.

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

Сам я работаю в тестирование уже 3 год, и поверти мне, мне есть с чем сравнивать, тесты на производительность Java приложений даже не заявляюсть так как только начни так сразу проц в полку лежит :)

12 августа 2007, 01:05:28

развод для лохов.
1. статически компилируем c/c++ и получаем java server method call в скоростной помойке
2. тест с постоянными границами массива? я тащусь с вас, робята! делаем malloc/new без константных размеров массивов и приплыли... однако проверка границ массива.


чувак, ты прыщавых школьников разводишь, или на Sun работаешь?

24 марта 2007, 21:24:05

Ещё бы Python бы сравнивли с Java, было бы вобще замечательно))) Каждый думает о своём.Сколько людей, столько и мнений)))) А сравнивать Java и С/С++, это нереально глупо. Вся JVM написана на С/С++.

27 февраля 2007, 08:57:20

Почитал комментарии... Лично я использую Java для написания кросс-платформенных приложений. Скоростью выполнения пренебрегаю, т.к. это не критичный момент на данном этапе. А тем, у кого меньше 512мб мозгов - совет докупить еще.

8 февраля 2007, 18:21:29

Да вы чего, ребята, Java-машина
вместе со своим знаменитым сборщиком
мусора пишется на чем ... как минимум
на С, возможно даже с использованием классов, а это уже
с++ (на чем же ей еще писаться не на асме конечно же),
А как С может работать быстрее самого себя????

К тому же если используется компилляция на лету,
то время этой компилляции почему никто не учитывает,
сравнивая выполнение программ, написанных на С++ и жава.

С++ дает все возможности для оптимизации, т.к. там
все просто и понятно: туды указатель, сюды указатель,
если не злоупотреблять множественным наследованием -все
быстро!
В жаве же все упирается в
реализацию конкретной машины (черный ящик),
т.е. в мозги конкретного
программиста, который ее писал. Ты можешь думать,
что ты оптимизируешь а на саммом деле ан, нет!
Машина все выполнит по своему!

Да и потом, запустить полноценное десктопное приложение
на жаве на какой-нибудь средней машинке (P 1000, 256мб)
-- ну реально тормозит!! Никакие тесты производить не
нужно! Особенно ГУИ!

А возьмем КПК -- AWT тормозит безбожно, а про
SWING и говорить не стоит!

17 августа 2006, 11:47:33

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

Вот мои версии программ:

Це++:

#include <iostream>
#include <stdlib.h>
#include <sys/time.h>
using namespace std;
unsigned long fib(unsigned long n) {
if (n < 2) return(1);
else return fib(n - 2) + fib(n - 1);
}
int main(int argc, char *argv[]) {
int n = ((argc >= 2) ? atoi(argv[1]) : 1);
struct timeval bt, et;
gettimeofday(&bt, NULL);
unsigned long f = fib(n);
gettimeofday(&et, NULL);
cout << f << endl;
cout << "Time: "
<< (float)(et.tv_sec-bt.tv_sec+(et.tv_usec-bt.tv_usec)*1e-6)
<< endl;
return(0);
}

Ява:

import java.util.Date;
public class fibo {
public static void main(String args[]) {
int n = Integer.parseInt(args[0]);
Date bt = new Date();
int f = fib(n);
Date et = new Date();
System.out.println(f);
long dt = et.getTime() - bt.getTime();
System.out.println("Time: " + String.valueOf(dt * 1e-3));
}
public static int fib(int n) {
if (n < 2) return 1;
return fib(n - 2) + fib(n - 1);
}
}

Результат оказалься довольно неожиданным:

#> ./fibo 40
165580141
Time: 6.4685
#> ./fibo 40
165580141
Time: 6.48078
#> java fibo 40
165580141
Time: 6.053
#> java fibo 40
165580141
Time: 6.03
#> java -server fibo 40
165580141
Time: 3.5620000000000003
#> java -server fibo 40
165580141
Time: 3.56

Duron 750 MHz, 256 MB RAM
ОС: Open SuSe Linux 10
JVM 1.5

6 августа 2006, 12:38:24

Ага, а html ещё быстрее, только он не фига не делает =)

5 августа 2006, 00:32:40

ПРО АВТОРА "ЦІЄЇ СТАТТІ":

Все что делает дурак,
все он делает не так !!!!!

Не статья, а какой-то бред! Просьба
к автору этой статьи:

Напиши на какой фирме ты работаешь и кем?
Такое ощущение, что ты видишь компьютер лишь тогда когда пишешь свои статьи!

23 июня 2006, 18:08:46

ребята о чем спор? как мы можем спорить о том что быстрее двоичный код или код который выполняется виртуальной машиной???? это гон. Не спорю: виртуальная машина может работать быстро, но почему же тогда винду на джаву не перенести?! или может на перл или баш?!

ЗЫ: спор "ни о чем" :)

6 мая 2005, 17:48:52

это все равно, что сравнивать теплое и мягкое. Java и С - это языки для разных целей. а с возможностями современной техники (имеется ввиду гигагерцы искорости и гигабайты оперативки и тд и тп), запросы (как упоминалось) JVM в 120 мегабайтах оперативки смотрятся не такой уж и критичной платой за кроссплатформенность

26 апреля 2005, 17:28:21

Замечания

1. При прочтении переводных статей надо обязательно смотреть источник.
Потому как переводят у нас...хмм... Сами переводчики называют это
"Специфика новостного перевода". В данном случае, заголовок переведён не
полностью, что и вызывает бурю эмоций. В оригинале заголовок говорит
_только_ об одном тесте на производительность - Unbiased Benchmark.
2. Как говорил aveugle надо присмотреться, по каким тестам шло сравнение.
Действительно, вызов функции в Java намного быстрее чем в C++. Так же
как, например, создание объекта
3. Для тех, кто считает Java "интерпр_и_татором". Это всё равно что сказать
что компиляторов C++ не существует, ибо сначала C++ переводится в C и
только потом C код компилируются (а это когда-то было именно так).
Ни Java, ни C# интерпретацию не используют, используется JIT компилятор (программа
компилируется налету из байт кода).

В тему

Оригинальную статью упрекнуть не в чем, тесты проведены предельно честно.

А вот _реальное_ сравнение производительности можно производить по разному
и по разным критериям. Если нас интересуют, скажем, игры - попробуйте
jake2, портированный Quake2 на Java
(http://www.bytonic.de/html/benchmarks.html).
По тамошним оценкам Java версия даёт в худшем случае 75% производительности
по отношению к C.

Кстати, на эту оценку и можно ориентироваться. За исключением GUI:

Есть несколько серьёзных проблем с производительностью GUI
- Память. На каждое Java приложение запускается своя виртуальная машина,
библитеки не расшариваются вообще (частично проблема решена в 5.0).
- Кроссплатформенность. За это надо платить, и до 1.4 плата была очень
велика. С каждой новой версией скорость работы увеличивается.
- Сборщик мусора. Актуально особенно вместе с проблемой памяти, когда
используется дисковая память.

С GUI трудно говорить о сравнении производительности. Если добавить
памяти побольше, то разница невелика. Но если памяти мало (или
запущено много приложений) - разница крайне существенна.
Остаётся добавить, что повышение производительности (одна виртуальная
машина на все Java приложения, расшаривание библиотек, снижение
издержек из-за кроссплатформенности, улучшение сборщика мусора)
одна из главных задач САНтехников на данных момент.

Итого

Java давно стала стандартом серверных приложений, увеличив
свою производительность до уровня C++. Для десктопов Java
по прежнему сильно отстаёт от С++.
Хотя терпеть уже можно (за кроссплатформенность, в частности)
и в будущем надеется есть на что.

P.S. (c) Никогда не читайте советских газет.

27 марта 2005, 09:49:22

Блин! Теперь каждый лабух будет мне рассказывать, что Java вставляет C++? Я б его отправил обратно во ВТУЗ, чтоб ему расталдычили, что такое интерпретатор
и что такое компилятор. Плюс к тому же: правильно написанная софтина на C++ приближается к ассемблеру(в частности распределённые вычисления). Но я согласен с тем, что каждому своё и понятие универсальности на самом деле применяется к определённому кругу задач, а не ко всему к чему попало, например строковый анализатор удобней писать на Perl, а производить долгие вычисления - на С++. Таким макаром: Java рулит в своей весовой категории, а С++ - в своей. Мораль: сравнивать С++
и Java - это тоже самое, что и сравнение самолёта с танком.

18 марта 2005, 17:34:06

читал статью и плакалЪ g++ - компилятор, java - интерпритатор... производительность у них что? наверное сам автор не сможет объяснить что именно там скрывается. и даже предположив что сравнивается скорость выполнения приблизительно аналогичных (по алгоритму) программ, то янемного в шоке, например для вычислений чисел Фибоначи, используя g++, хватит и 386 процессора, а если нам потребовались серверные настройки и 512 метров памяти на п4 что бы ускорить java-приложение ... нюню ... действительно шустрик вышел :)

Счас на моей машине запущены C++ Builder & JBuilder .. (оба от борланда, один написан на си, второй на яве насколько я знаю ... яркие примеры) ... и почему это интересно СиБилдер под себя забрал 40 Мб памяти, а более примитивный ДжБилдер 120 ...? да ещё и тупит при этом страшно? :)

Кароче КГ\АМ

2 марта 2005, 15:21:01

Всё-таки придерживаюсь мнения, что следует писать Java (джава если ломает переключаться) а не "ява", так как это название зарезервировано островом и сортом чая

2 марта 2005, 15:17:56

По личному опыту работы с Java твёрдо сформировались следующие убеждение (широко распространённое среди коллег, кстати)
По производительности (кстати, IMHO в названии статьи Java используется в контексте "платформа", а не "язык программирования") Java на вполне приличном уровне, опережает .NET-based programs во всех виденых мною случаев.
2 Dima: Оглянись, везде: IBM DB2, Oracle 10g - только среди СУБД.
среди enterprise-level software - более 75% на Java
2 Mike: Для вышеупомянутого enterprise-level software С++ не используется ввиду сложности создания/развёртывания/саппорта/дороговизны IDE (вы ведь используете легально приобретённую копию MS Visual Studio.net) и т.д.

1 февраля 2005, 15:56:51

У языка программирования не может быть ПРОИЗВОДИТЕЛЬНОСТИ.

30 января 2005, 00:49:45

поправки (писал быстро):
в пункте 1: ... т.к. мы НЕ должны будем создавать объекты внутри ф-и...
в пункте 3: скорость выполнения увеличится

30 января 2005, 00:46:24

<ul><li>не используем функции возвращающие значения (переменные которые должны принять какое-то значение после работы ф-и помещаем в качестве параметров, как укозатели) (уменьшается время используемое на передачу данных, т.к. мы должны будем создавать внутри функции объекты и снаружи функции объекты)

<li>используем только inline функци (тем самым исключаем время вызовов ф-й - мало, но всёже)

<li>скорость работы циклов можно увеличить используя вместо увелечения на 1 умножение на 2 (сдвиг на один разряд влево - скорость выполнения значительно уменьшается)

<li>скорость работы циклов заменяем сравнение на деление на 2 (если использовать счётчик смещением) и вычитание, а затем сравнение с нулём (2 "тик"_а в худшем случае, т.к. проверяется флаг на "ноль" и на "отрицательное")
</ul>

если уж совсем извратиться то можно использовать везде только адресную арифметику и работать восновном с укозателями - ещё снижение затрачиваемого времени.

ВЫВОД: не умеешь хорошо программировать на Си - не берись "сравнивать на весь мир". Вот если бы то-же самое написал г-н Бьярн Страуструп или, в крайнем случае, г-н Линус Торвальдс (тестили в линухах), то я может даже и поверил на слово.

20 декабря 2004, 18:57:31

На таких "базовых" тестах производительность C/C++
не должна уступать Java. При этом Java не сильно отстаёт потому что JVM (особенно -server) в последнее время не интерпретирует байт-код, а старается преобразовать его в машинный код процессора.G+ и GCC мне совершенно не знакомы. Для тестов справедливее было выбрать последние компиляторы с заточенной оптимизацией под Пентиум 4 или AMD -- куда справедливее (особенно если уж мы такие умные и знаем что такое -server).В грубой силе C/C++ всегда будет обгонять Java. А вот по итоговой производительности приложения -- от языка программирования это зависит в меньшей степени...
...тут нужны мозги
P.S.
Для подсчёта контрольной суммы (MD5) файлов было написано 3-ри программы на C/C++, Java и Perl -- разница времени выполнения на данных объёмом около 1Г составила несколько секунд (статистическая ошибка?). Производительность HDD куда более существенный фактор

27 августа 2004, 12:43:04

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

12 августа 2004, 22:31:13

Нужно присмотреться к тому, по чем шло сравнение.
По встроеным функциям?

Так бейсик в верде может оказаться быстрее чистого c.

:-)

5 августа 2004, 13:12:50

С каких пор интерпритация команд быстрее непосредственного выполнения...

21 июля 2004, 23:25:16

Ява всегда останется явой, а C всегда С. Думаю, что ни один из этих языков не вытеснит другой.

13 июля 2004, 19:06:22

вешайте эту лапшу на ущи моей бабушке

13 июля 2004, 17:46:10

У меня напрашивается анлогия - Запорожец ездит быстрее чем BMW ездит задом.

13 июля 2004, 14:19:56

ерунда
если Java такая быстрая то где быстрые программы написанные на Java ?