Java — тормозит, а Cи — нет?

Question

[Lici]

Я вообще не разбираюсь в Java и С++ знаю не сказать, что профессионально. Вопрос нубский.

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

Основано это исключительно на опыте работы с ПО, написанном на разных языках. Все, что написано на Java, по ощущениям работает медленнее и грузит сильнее.

Прав ли я в своем мнении?

Comments

[Lici]

Я понимаю, что можно и на С написать тупаря и на яве шуструю программу, но почему все, что на джаве такое тупое?

[Lici]

Тупое в плане скорости работы.

Answer 1

[Rsa97]

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

Comments

[Егор Михеев]

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

[Rsa97]

матрунич сергей: А смысл? Для этого есть другие языки. C как раз хорош тем, что программист может (и должен) контролировать всё, что делает программа.

[Егор Михеев]

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

[Rsa97]

матрунич сергей: Не везде можно обвешивать задачу различными автоматами. Есть программирование микроконтроллеров, где ограничен объём памяти, есть системы реального времени, где надо уложить реакцию на событие в строго определённый интервал времени...
Переходить с мягкой типизации или бестипового языка на строгие типы тоже напряжно, при этом можно поймать кучу глюков вида ('1' == 1).

[Егор Михеев]

По поводу микроконтроллеров тут просто, программа перед компиляцией сама приводит код к типизации, по поводу остального - соглашения и методология

[Алексей Черемисин]

матрунич сергей: "соглашения и методология" - работают до тех пор, пока их НЕУКОСНИТЕЛЬНО соблюдают. Как только один начнет оптимизировать, а он непременно нечнет, посыпятся все и сразу. Так что можно сказать, что Эсоглашения и методология" не работают, если их нельзя контролировать. А контроль в программировании только один - компилятор, ну еще и тесты, но тесты пишутся для программы, которую пишут программисты :-)
К слову, в свое время С++ как раз и был оберткой над С, компилировался в С-код, который компилировался в машинный обыкновенным С-компилятором. Ну и в результате все обертки переросли в собственные компиляторы, и стали независимыми языками программирования.
А если хочется оберток, то берите предпроцессор M4 и вперед, хоть С из него получайте, хоть С++. Только в результате у вас получится собственный язык программирования типа Objective-C или Swift.

[Rsa97]

матрунич сергей: И как программа должна привести данное выражение?
('1' == 1) -> (atoi('1') == 1) или
('1' == 1) -> ('1' == (char *)1)

[Алексей Черемисин]

Rsa97: А мне вот так нравится, секурненько, и по производительности ничо так ...
('1' == 1) -> в следующий код :-)

int _d_07752 = 0;
sscanf('1',"%d",&_d_07752);
... (_d_07752 == 1) ....

Answer 2

[Ярослав Корнилов]

Что более тормозное русский или китайский язык? По - моему китайский, а китайцу кажется, что русский более тормозной.
Теоретически С++ МОЖЕТ быть быстрее из-за того что он сразу "переводится" в машинный код, но это несет за собой уменьшение управляемости и скорости написания кода.
Но в реальности расход ресурсов зависит от архитектуры программы и используемых алгоритмов.
Поэтому однозначно сказать нельзя.

Answer 3

[Алексей Черемисин]

Соглашусь, что ява медленная лишь отчасти. Медленная она только в одном - при старте приложения. Далее, когда приложение уже стартануло и произвела всю компиляцию JIT, то скорость очень даже сравнима с с кодом на C/C++. Ну так меделнный старт свойственен всем языкам с виртуалкой и тут нечего плакаться. Ну-ка попробуйте за недельку сделать приложение с динамической подгрузкой плагинов, работой с базой, балансингом и обслуживающий тысячи коннектов. Если получилось это на C/C++, то поздравляю, но у вас получился неуклюжий глючный монстр, вылетающий в core.

Comments

[Алексей Кулаков]

А в Java Jit-компилятор все компилит в начале или по мере надобности?

[Алексей Черемисин]

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

Answer 4

[Михаил Алексеев]

benchmarksgame.alioth.debian.org/u64q/java.php

Answer 5

[Андрей Крыцкий]

В таких случаях я всегда вспоминаю цитату из рекламы "просто ты не умеешь их готовить"

Природу не обманешь. И для Java и для C++ все выливается в native-код, который выполняется одинаково. И, например, начиная в С++ с прямой работой с буферами (якобы для ускорения) человек приходит к "умным указателям", собственным аллокаторами, а в хорошем случае к библиотекам (boost, stl).

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

И еще мысль. В большинстве случаев тенденция такова, что важнее, чтобы код создавался быстрее, а не выполнялся. "Узкие", особые места оптимизируются по алгоритму предложенному xandox выше в ответах.

Answer 6

[xandox]

Да не, и на java можно писать так что бы не тормозило. Только почему-то никто этого не делает...

Comments

[Lici]

ВОТ! Почему? Почему все, что на джаве - убийственно тупящее?

[xandox]

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

[Алексей Черемисин]

А вы "индусов" не нанимайте, будет всё хорошо, будут программисты использовать NIO, bytebuffer и прочие полезняшки. Приложения просто летать будут.

[xandox]

ну-ну что же тогда не одно java-приложение не летает? Все java-исты индусы?

[Алексей Черемисин]

Примеры в студию! Что у вас не летает?

[xandox]

да пожалуйста
cassandra - на каком-то смешном объеме данных в чуть больше теробайта имея три реплики на довольно неплохих (64GB оперативы и 8 ядер) серверах умудряется тупить и отваливаться по таймауту при запросах
fop - это чудо техники инженерной мысли падает по out of memory так часто, что уже грустно становиться
про java based IDE - я вообще молчу, что бы там работать нужно обладать по истине ангельским терпением.

[Алексей Черемисин]

ух, какие тяжелые вещи! FOP пытались применить лет 10 назад, он и тогда был шаг влево - расстрел, в результате использовали iText! Cassandra - не пользовал, но отзывы странные тоже. Eclipse пользую постоянно - ничего не тормозит, разрабатываю под ним и на яве, и питоне и С. Да, для разработки использую белый макбук и 8Гб памяти, и менять пока не хочу - хватает. Работал в свое время с Eclipse BIRT - шустрая штука, понравилось больше, чем Crystal Report...

Answer 7

[Odissey Nemo]

Числодробительный код на Java примерно в 2-3 раза медленнее, чем на С++ или, скажем, Delphi. Так кажется на собственной субъективном опыте. Т.к. на Java слишком много разных фич пристыкованы в байт-коде чисто механически.

Но писать программы со вполне удовлетворительным быстродействием вполне можно. Даже нумерологические. Скажем, полная обработка растров размерами 10000 на 10000 (бинаризация или другие матричные фильтры) средствами собственного кода (без нативных библиотек) вполне отрабатывает за секунды. Не утомляя пользователя. Но!Тут и встаёт вопрос о знании алгоритмов, вернее, какой где стоит применить.

Answer 8

[Ilya Bobkov]

си - получше будет

Comments

[Алексей Черемисин]

Ну, да, конечно! Ассемблер еще лучше! Без вопросов.

[cthulhudx]

Алексей Черемисин: Машинные коды круче

[Алексей Черемисин]

cthulhudx: На перфокартах.