Java быстрее С++ помогите восстановить справедливость

gcc main.c -std=c99 -O3

-O4 сделай

только не говори ему, что gcc тут напрочь все выкинет как ненужное

с++
gcc main.c -std=c99

o_O

Код легкий

зачем же легкий? возьмите какую нибудь реальную задачу из жизни например какую нибудь работу с файлами (парсинг, конвертация), пускай он ПОПРОБУЕТ приблизится к сливу хотя бы в 10 раз)))

Однако в java он выполняется в 5 раз быстрее чем в с++

Приведенный код вообще не имеет эффекта. JIT может его просто выбросить %)

Приведенный код вообще не имеет эффекта. JIT может его просто выбросить %)

во-во

impossibru

Результат хотя бы вывели на печать.

Так что не спеши печалится, самое время поднимать ставки ибо жаба сольет конкретно, но жабаколлега твой из за каких тестов уверен в обратном)))

Да уж. Это даже не смешно.

Мы на примере заметили что результат приходится выводить, в java также

Я когда-то без всякого выкидывания кода оптимизатором был вельми поражён :D — http://www.balancer.ru/tech/forum/2005/03/t32510--ya-ne-veryu-svoim-glazam-ja...

я просто оставлю это здесь.

Java слила по скорости в 3 раза. =)

я просто оставлю это здесь.

фигня сплошная синтетика, по всем этим тестам оно уже быстрее машкода)))

Мы взяли самый простой, чтоб бы не заморачиваться на разность алгоритмов

Java слила по скорости в 3 раза. =)

опять же слишком синтетический тест, чем более реальную задачу возьмем тем ощутимей будет слив)

Я когда-то без всякого выкидывания кода оптимизатором был вельми поражён :D

тут можно сказать только одно - msvc отстой и даже не поддерживает(не поддерживал) стандарт, g++ выдал код в два раза быстрее чем java

Мы взяли самый простой, чтоб бы не заморачиваться на разность алгоритмов

Например есть некий графический файл - создайте консольную тулзу которая будет его парсить вырезать заданный квадрат (координаты из командной строки), поворачивать его на 90 градусов и сохранять в другой графический файл. Все напишите с нуля - парсинг формата файла, поворот, формирование формата файла. Ты на C, а он на жабе))))))))

тут можно сказать только одно - msvc отстой

Ну-ну :D В те времена на тех же тестах и железе он рвал GCC как тузик^W, скажем, и ICC.

Как сейчас — не в курсе. Но, насколько знаю, ICC по-прежнему быстрее, чем GCC.

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

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

С чего бы алгоритмов то? Пускай он берет твой алгоритм)

Java подобный код просто выкидывает, там около 120 оптимизаций встроено для всяких хитрых сценариев. Ты же его не выводишь. Хочешь чтобы Java слила, напряги GC, на такой синтетической математике она умнее плюсов. Привильно упомянули парсер, в котором скорее всего сильно бросаются во все стороны обьектами. Но возможно и нормально написали парсер, тогда может будет и то же самое.

Если ты упоролся засвидетельствовать слив на математике, то примером могут быть различные битовые операции, когда из-за отсутствия беззнаковых типов ты городишь костыли.

Хочешь найти слив плюсов, то подбери алгоритм, который нельзя написать без активной работы с памятью, new в Java работает со скоростью стека С++, О(1), плюс амортизированый «на потом» оверхед GC. Они со своим new, delete сольют очень сильно, Java одним махом все чистит.

Это все пиписькомерство, британские ученные. В реальном мире на Java проще применить нормальные подходы и структуры данных, потому в Java приложении они будут с больше вероятностью, а С++ они тоже есть, но их могут не осилить или забить как на лишнюю сложность.

Хочешь чтобы Java слила, напряги GC, на такой синтетической математике она умнее плюсов.

Только если плюсы используют стек. На использовании хипа плюсы уже могут сливать: http://www.balancer.ru/g/p1618859

Да, верно. Я как раз имел ввиду то что вы говорите. Дальше я упомянул что если у обоих будет хип, то плюсы крепко попали

Дальше я упомянул

Тьфу, я начал отвечать и забыл дочитать сообщение до конца :)

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

Почему Swing тормозит? Не потому, что он на яве, а прежде всего потому, что там такие алгоритмы. У явы старт медленный, потребляет больше памяти, и иногда бывают ощутимые задержки из-за сборки мусора. При этом мы имеем очень быстрый new, гораздо быстрее сишного malloc, и имеем автоматическую дефрагментацию памяти, что очень важно для серверных приложений, работающих в режиме 7 x 24.

Ну-ну :D В те времена на тех же тестах и железе он рвал GCC как тузик^W, скажем, и ICC.

прочитай там свой же первый комментарий, т.е. gcc обгонял java, java обгоняла msvc, но msvc «на тех же тестах» рвал gcc как тузик? оригинальная у тебя логика

Добавлю очевидную вещь: а язык программирования влияет на то, какие алгоритмы могут быть применены в рамках конкретного языка, иногда очень сильно, причем язык даже влияет на то, как формулируется задача.

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

На одной машине Java рвёт MSVC

На другой — GCC рвёт Java.

На первой же их этих машин GCC/Win32 в те же времена уступал по скорости MSVC и заметно.

А на счёт других машин, ты, опять же, не дочитал до тестов, где у людей, наоборот, MSVC быстрее, чем Java.

Однако в java он выполняется в 5 раз быстрее чем в с++. Помогите с параметрами компиляции, чтобы приблизиться к показателям java

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

На первой же их этих машин GCC/Win32 в те же времена уступал по скорости MSVC и заметно.

а я помню, что у меня mingw рвал msvc 2005 на подобных мелких задачках

А на счёт других машин, ты, опять же, не дочитал до тестов, где у людей, наоборот, MSVC быстрее, чем Java.

т.е. на основании этих результатов не имеет смысла делать однозначный вывод о производительности

Так основная задержка - это именно цикл! Без оптимизатора сишный код далеко прогадил, а вот в яве оптимизатор встроенный, хотим мы этого или нет.

Там есть оптимизация компилятора, но оно еще рантайме оптимизирует нехило, плюс применяет profile guided optimization. Java не надо быстро работать после старта, тут лучше другие ЯП справятся. Ей надо гонять гектары после получасовой раскачки и профилирования на серверной стойке

Сливать джаву надо тормозными стандартными библиотеками и всякими полудокументированными фичами. Правда такое найти может быть сложно, надо постараться. Ещё можно невзначай использовать алгоритмы разной сложности, строки там в цикле поскладывать, или домом иксмл разобрать, против сакса на плюсах. В последних версиях джавы вроде убрали шаринг буфера при substr, можно потролить спецов, которые будут делать substr от огромной строки будучи уверенными, что буфер шарится и substr будет моментальным. Еще можно незаметный автобоксинг сделать, легким движением руки byte превращается в килобайтный Integer.

Высший пилотаж - написать код так, чтобы на плюсах он кеш процессора по полной использовал, а на джаве разваливал на каждой итерации, циклы по разным координатам например сделать. Или опять же вместо примитивов объекты заюзать, какой там кеш, gc сплошной будет.

Че серьезно убрали? Тупняк же. Посмотрю в сорцах при первой возможности

Помню как вроде кто-то LinkedList бенчмаркал вместе с плюсовым аналогом. А если JVM видит «структуру похожую на linked list», тоесть (value,next) паттерн, то она переставляет их подряд в памяти, получив ArrayList-like по утилизации кеша

http://www.rsdn.ru/forum/java/4988346.all

Видимо слишком много индусов держали большие строки ссылками из маленьких.

Это хорошо, значит можно попробовать сделать «одинаковый» код, в котором С++ будет сливать со свистом :)

Не кешем единым. Не факт, мало ли что там будет. В том бенчмарке свои особенности, в чем то другие. Но такая оптимизация имела место. Надо будет когда-то самому запилить

Или опять же вместо примитивов объекты заюзать

Покажите как в Java сделать эффективный тип данных для комплексных чисел, чтобы и более или менее удобно использовать, и чтобы не тормозило.

Особенно интересна реализация эффективных массивов из комплексных чисел, чтобы там не ссылки на объекты были, а сплошной кусок памяти как в C++/C#.

т.е. на основании этих результатов не имеет смысла делать однозначный вывод о производительности

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

class Complex {
    private final double[] data;
    private final int index;

    Complex(double[] data, int index) ...

    public double re() { return data[index]; }
    public double im() { return data[index + 1]; }
    ...

Потом добавить класс ComplexVector, думаю понятно как. Вроде эффективнее некуда, использовать несложно. Ну или сразу писать api для вектора, смотря какие вычисления нужно делать.

Так основная задержка - это именно цикл!

Ну так компилятор в данном случае его выбросит нафиг.

Без оптимизатора сишный код далеко прогадил,

То есть вы принципиально отключаете оптимизацию, что бы сишный код слил яве? Ну ок, дело ваше.

а вот в яве оптимизатор встроенный, хотим мы этого или нет.

Только толку от него не много. На реальных задачах ява-приложения тупят по самое не хочу.

Что это за странная конструкция? Похожа на какой-то 2-х элементный срез массива, разве это комплексные числа?

Нужен простой/удобный/эффективный тип для комплексных чисел, который затем можно использовать в векторах/матрицах так, чтобы все данные лежали одним куском памяти без лишней косвенности при обращении к элементам.

Добавлять специальный класс ComplexVector вообще странная идея, в C#/C++ можно написать на generics/template и оно будет работать универсально и без всяких лишних размещений объектов в куче.

В джаве данные лежат одним куском только в массиве элементов примитивного типа. Комплексное число это пара действительных чисел, где они хранятся — не важно. Поэтому если тебе надо хранить данные с минимальным оверхедом, других вариантов кроме как хранить их парами в массиве (или в двух массивах) нет. Обобщенный класс для примитивных типов не написать, придется копипастить или использовать внешний препроцессор/кодогенератор. value-классов в джаве тоже нет, поэтому их придется имитировать.

Поэтому если тебе надо хранить данные с минимальным оверхедом, других вариантов кроме как хранить их парами в массиве (или в двух массивах) нет. Обобщенный класс для примитивных типов не написать, придется копипастить или использовать внешний препроцессор/кодогенератор. value-классов в джаве тоже нет, поэтому их придется имитировать.

Это все так, и Java(JVM) от этого лучше не становится. На ней не очень удобно реализовывать эффективные вычисления в отличии от C++/C#. Так что про информация про «быстроту» Java не совсем верная.

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

Взяли бы любой алгорим на графах, того же дейкстру или прима или ещё проще - DFS/BFS.