Войти
ПрограммированиеФорумОбщее

Java / C++

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 Следующая »
#0
6:48, 25 янв. 2006

Можно ли как-то "разогнать" Java до скорости C++?

Может существуют компиляторы Java не в байт код, а в машинный?
или может есть JRE быстрее Sun'овского?


#1
10:58, 25 янв. 2006

Upiter
До скорости С++, жабу не разогнать - это факт, ей ++ будут мешать при разгоне, а вот до скорости С, вполне.
Берешь синхрофазатрон, в простонародие ускоритель, засовываешь в него жабу, и разгоняешь. Конечно, разогнать жабу именно до скорости С, вряд ли получится - вредный старичок Эйнштейн будет постоянно ее притормаживать, но результаты вполне приемлемые.

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

#2
11:30, 25 янв. 2006

> Может существуют компиляторы Java не в байт код, а в машинный?
все современные java машины используют JIT компиляторы. Т.е. на этапе выполнения мы получаем машинный код.
Компиляция в машинный код байт-кода просто так  вредит парадигме жабы.

> есть JRE быстрее Sun'овского?
Ну во первых сам Сан предлагает две версии своей машины, а во вторых IBM жаба-машина рулит (их Lotus обязывает :) за единственным недостатком она всегда отстаёт от сановской на одну-две минорных версии.

> До скорости С++ жабу не разогнать - это факт
Ну тут смотря каких пропагандистов читать :) некоторые утверждают что коллекции в java решают для серверных приложений всё что создано с помощью надомных реализаций STL... А кое-кто, что она вообще решает :D
А вот тут более менее доступно объясняют что и как.

но вообще, области применения разные и толку сравнивать производительность нет. Можно возможности perl'a и скорость его работы с OpenGL сравнить c  C++ и DX. Я не сомневаюсь кто победит.

#3
12:12, 25 янв. 2006

Glorg
>Ну тут смотря каких пропагандистов читать :) некоторые утверждают что коллекции в java решают для серверных >приложений всё что создано с помощью надомных реализаций STL... А кое-кто, что она вообще решает :D
>А вот тут более менее доступно объясняют что и как
цсс... это секретная информация.... никто не должен знать, что вся теория Эйнштейна, основанная на том что С - максимально возможная скорость, на самом деле - массонский заговор, организованный с единственной целью: засунуть жабу в ускоритель и радостно хихикая, наблюдать, как у бедного земноводного при разгоне начинают выпучиваться глаза и отрываться конечности.

#4
16:18, 25 янв. 2006

Glorg
Спасибо за ссылки. Миф о тормознутости явы для меня окончательно развеян.

xmvlad
Это ты к чему?

#5
18:39, 25 янв. 2006

Jakobz
>Спасибо за ссылки. Миф о тормознутости явы для меня окончательно развеян.
Наивняк :)

Наивняк :)
Все от задачи и от кода.
Они во первых в тестах использовали баговую строку оптимизации для gcc3.2 -march=pentium4 -mcpu=pentium4 и -O2 и выше + пофигу какие еще ключи дает такой код который можно сразу удалять. С оптимизацией в гцц до сих пор проблемы - при некоторых ключах все тормозить начинает а при некоторых вообще отказывается работать, но все от того что ты компилишь зависит.
Например нельзя использовать О3 и -msse2 -march=pentium4 -mmmx для компиляции X.Org - тормознее все сразу станет причем на глаз где-то вдвое.

Во вторых. Все упирается в задачу. Если у тебя просто вычислительная задача, то побеждает оптимизатор :)
Если задача посложнее то и результаты будут совсем другими. Например выделение памяти в Java и С++ с помощью
абстрактных фабрик показывает, что благодаря рефлекшену Ява иногда на 20% тормознее. Да , фактори С++ на тэмплэйтах - тоесть
статично определена функциональность на этапе компиляции, и в рантайм ты ее не изменишь.
Например сравнение строк очень хороший тест-кейс. Тут реально будет тестироваться оптимальность кода libc и java-овского.
В идеале пр-ть должна быть одна и та-же. Но даже в этой ситуации не все так просто.
У меня к примеру дома оптимизованая glibc-2.3.6-r2 (х86_64)- в ней оптимизация по выделению и копированию памяти.
По тестам моя машина дома имеет на 8% лучший рейтинг для этих тестов, чем подобные машины на работе, при этом на работе 2.4Гц процы,а дома 2Гц. В абсолютных цифрах рабочие машинке быстрее (все-таки помощнее сами по себе). Но на приложениях - (например билд всей системы) моя 2-х ядерная малышка, 4-х процессорные по времени бьет. Тоесть если я дома собираю систему целиком за 4-е часа то такую-же систему 4-х процессорные тачки собирают за 12 :)

И ведь это все на С/С++. Почувствуйте разницу.
Выбор платформы разработки не должен опираться на пр-в-ть компилятора. Компиляторов много и они разные, стандарт языка один.
Если твоя задача решается(разрабатывается) на Java хотя-бы на 10% быстрее, чем на любом другом языке, то используй Java.
Или если тебе легче понять исходный  код Java, и всем кто с тобой вместе работают тоже, то выбор Java.
Если тебя тошнит от отсутствия или кастрированости шаблонов в Java, то твой выбор С++.
Главные критерии при выборе тулчейн - как быстро с этим набором софта быдет реализован тот или иной проект, и как легко будет его в последствии сопровождать.


Я бы давно на Java перешел и для своих хобби проектов, если-бы меня от нее не тошнило. Одно громадное преимущество есть теперь у Java именно для таких людей как я. Для тех кто не может себе позволить выложить $2000-$4000 за приличную UML среду интегрированую в IDE. Большинство бесплатных или Community Edition UML инструментов поддерживают С++ только за деньги, причем не малые. Интеграция в любимый IDE стоит тоже нехило. А недорогие UML тулзы очень часто не дотягивают до необходимого тебе уровня.

Несмотря на это на Java я все равно переходить дома не стану - мне с Java не уютно (не люблю гробы на колосах).

aka acs.

#6
17:24, 27 янв. 2006

xmvlad
>PS: эх... что за молодежь пошла, знали бы твои деды, как ты здесь жаб разгоняешь - сгорели бы со стыда, у них-то ведь ни >жаб, ни ускорителей не было, все приходилось по старинке делать - руками и этим, как его..... лобзиком.

Ты бы на жабе 2 года без плюсов просидел :) и не до того бы дошло.

Glorg
>Компиляция в машинный код байт-кода просто так вредит парадигме жабы.
Этот байт код постоянно проверяет выход за пределы массива:

int[] a = new int[1024];
for (int i=0; i<1024; i++){
    a=i;
}

кроме 1024 присваиваний значения будет произведено 1024 проверки выхода за массив.

Arrays.fill вообще убитый вариант (кт охочет посмотрите src)

Прошло более 3 лет
#7
16:11, 18 сен. 2009

От Javы тошнит, потому-что у нее нету ни одной среды разработки вменяемой(лично меня тошнит именно от них). Если бы у тебя вместо MVS .NET был бы eclipsе или Idea для C#, то тебя бы не меньше тошнило от последнего. Все решает среда применения - если в корпоративной сети стоит сервер под Linux/Unix, юзеры под виндой и еще ноутбуки под MacOS подключаются, а при это нужно однородность и универсальность рабочей среды для работника корпорации обеспечить, то альтернативы Javе нету, тк это единственная на данный момент реальная кросс-платформенность, что бы там не плели про .NET

#8
16:40, 18 сен. 2009

Upiter
> Может существуют компиляторы Java не в байт код, а в машинный?

gcj ?  Но до скорости нативного кода, всё равно не "разогнать".

#9
17:07, 18 сен. 2009

Mungust
> Все решает среда применения - если в корпоративной сети стоит сервер под
> Linux/Unix, юзеры под виндой и еще ноутбуки под MacOS подключаются, а при это
> нужно однородность и универсальность рабочей среды для работника корпорации
> обеспечить, то альтернативы Javе нету

QCreator, норм пока нравится.

#10
17:36, 18 сен. 2009

> От Javы тошнит, потому-что у нее нету ни одной среды разработки вменяемой
Врятли. Попробуй Netbeans.

#11
20:25, 18 сен. 2009

IDEA еще посмотри. Я не Java программист, но рядом народ использует.

#12
21:31, 18 сен. 2009

Всем по лопате =))))))))))))

#13
22:06, 18 сен. 2009

аххаха. Ещё чуток и можно было бы праздновать 4-ёх летний юбилей ))

#14
22:39, 18 сен. 2009

Ааа, во что  ввязался?! =)

ЗЫ Хотя предводитель мог создать отдельную тему для ИДЕ под яву. Так все было бы логичней.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.