LINUX.ORG.RU

Производительность Java, C и C++

 , , ,


4

7

Предположим я не тролль, а правда знаю C, C++ и Java.

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

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

Вопрос: чем вызвано массовое увлечение написанием десктопного ПО на java, ведь явного «горячего пути» в десктопных ПО обычно не существует?

ЗЫ программисты на Qt, а не на C++ проходите мимо, вопрос к людям постарше.

Ответ на: комментарий от clover

тебя похоже били и насиловали программисты на Хаскеле

Ты бредишь :-) Займись делом :-) Напиши что-нибудь дельное на Java :-) Хаскель, кроме понтов, ничего тебе не даст :-) А то так и будешь с дырками в карманах ходить неудовлетворённый, закорючки в уме сочинять :-) Лол :-)

anonymous ()

ведь явного «горячего пути» в десктопных ПО обычно не существует

Поэтому браузер надо взять на UI, а бекенд пилить на джаве и будет всем счастье ) Это еще SaaS называется.

foror ★★ ()
Ответ на: комментарий от clover

может быть боится потерять аудиторию?

Скорее не хотят переписывать с нуля и набирать новое ядро разрабов.

Почему бизнес не выпускает массовых продуктов на java?

Выпускает, просто на сервер-сайде она не видна.

foror ★★ ()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от foror

Поэтому браузер надо взять на UI, а бекенд пилить на джаве и будет всем счастье ) Это еще SaaS называется.

да ты у нас самый модный в этом чате!

anonymous ()
Ответ на: комментарий от anonymous

Не без этого, слежу за модой ) Кстати, в Ubuntu думают об этом пути, какой-то браузер на базе хрома очень давно завезли - Ubuntu Web Browser называется. В даше можно найти набрав browser или в консоле webbrowser-app --help

foror ★★ ()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от eao197

я рассматривала вопрос именно так.

ухудшилось: притащили в стандарт много ненужного. всё, что раньше спокойно существовало отдельно, теперь теперь тащится в стандартной библиотеке. увеличивая её вес и ухудшая реализацию. распухли темплейты, хотя это совершенно побочная вещь, и не надо из них делать отдельный тьюринг-полный язык, необходимости в котором нет. появилось много синтаксического сахара типа лямбд. вот были они отдельно в библиотеках, наверное, ещё с 90-х годов - и никому не было до них дела. никто их не юзал, кроме пары фанатов. какой смысл был тащить ненужно, которым никто не пользуется, в стандарт? в результате нубы и прочие адепты этого фуфла создают монстрозный софт, который дискредитирует плюсы. конечно, можно игнорировать всё УГ и писать нормальный код. но сам компилятор становится сложнее, его сложнее реализовывать под разные платформы. то есть, количество платформ сокращается из-за фигни. и остаётся открытым вопрос: какие такие соображения сподвигли всё это тащить в стандарт? а некоторые базовые вещи (например, итераторы по enum) так и не реализованы.

и, пожалуй, самое гнусное: допустимость реализаций с GC. начиная с С++11 зашёл разговор о GC и даже о «strict pointer safety» (у меня нет приличных слов, чтобы это перевести на русский язык). и это принципиальная проблема. если стандарт опустился до такого, то дальше я не знаю, что будет.

Iron_Bug ★★ ()
Ответ на: комментарий от Iron_Bug

Да уж, практически все изложенное — это просто лютый ППЦ. Вы, походу, из тех, кто предпочитает закатывать Солнце вручную, а любой прогресс, облегчающий эту задачу для вас является ересью. Мне даже страшно представить, во что вылилось бы в вашем исполнении решение вот такой частной проблемы без применения фич современного C++.

Пожалуй, единственный более-менее объективный довод в вашем потоке сознания — это: «но сам компилятор становится сложнее, его сложнее реализовывать под разные платформы». Но это проблемы совершенно ничтожного процента C++ разработчиков (тех, кто занимается компиляторостроением). Если пара сотен компиляторописателей поработает чуть напряженнее, то это вполне приемлемая цена за то, чтобы миллиону прикладников было проще использовать C++. Да и развитие компиляторостроения не стоит на месте, так что в реальности все может быть совсем не так страшно, как вам кажется.

eao197 ★★★★ ()
Ответ на: комментарий от eao197

Какие-то очень сложные ссылки для промышленного эмбеддера, у которого самая сложная задача - ногой подрыгать по закону, описанному в учебнике по ТАУ 60-х годов. А, ну еще Очень Сложные Алгоритмы, типа численного интегрирования или, не дай бог, FFT. Тут без мехмата никак.

Какой еще policy-based design? Что это? Дали спецификацию, которая не поменяется лет 10 - хуярь. Приемку прошел - молодец, можно пойти на лор и порассказывать про нубов и моск

anonymous ()
Ответ на: комментарий от Iron_Bug

вот были они отдельно в библиотеках, наверное, ещё с 90-х годов - и никому не было до них дела. никто их не юзал, кроме пары фанатов

Может потому и не использовали, что библиотечная реализация была отстоем?

притащили в стандарт много ненужного

Я думал, намного будет… Намного лучше будет это все. ©

DarkEld3r ★★★★ ()
Ответ на: комментарий от eao197

да вот пожалуй

у тебя либо какой-то комплекс непризнания, либо ты младший разраб в команде whom nobody likes. твои нападки на тётку , хотя это даже не нападки, а какое-то хвастовство знанием c++, как бы намекают.

anonymous ()
Ответ на: комментарий от foror

Не без этого, слежу за модой ) Кстати, в Ubuntu думают об этом пути, какой-то браузер на базе хрома очень давно завезли - Ubuntu Web Browser называется. В даше можно найти набрав browser или в консоле webbrowser-app --help

на-сколько я помню пара попыток совершить этот «инновационный прорыв»(тм) закончились ничем, ибо бред

clover ()
Ответ на: комментарий от Iron_Bug

и, пожалуй, самое гнусное: допустимость реализаций с GC. начиная с С++11 зашёл разговор о GC и даже о «strict pointer safety» (у меня нет приличных слов, чтобы это перевести на русский язык). и это принципиальная проблема. если стандарт опустился до такого, то дальше я не знаю, что будет.

В комитете идет много разговоров, всяких и разных. GC как раз очень сомнительная фича и маловероятно, что она когда-нибудь войдет в стандарт

clover ()
Ответ на: комментарий от anonymous

Проницательный вы наш, вы делаете такие фантастические предположения и так хорошо сами себя убеждаете в их правильности, что возникает вопрос: зачем вам промежуточное звено в виде LOR-а?

eao197 ★★★★ ()
Ответ на: комментарий от clover

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

foror ★★ ()
Ответ на: комментарий от foror

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

о, да) еще один умник за все человечество отчитывается) андроид - не десктоп, а хромоось всему человечеству так прям нравится, что даже слеза навернулась:

http://gs.statcounter.com/os-market-share/desktop

clover ()
Ответ на: комментарий от Iron_Bug

ухудшилось:

при таком знании с++ критиковать его это «я пастернака не читал, но осуждаю»

вот что я бы написал о недостатках перехода с си на с++ (о достоинствах ниже):

1. переход с си на с++ имеет недостатки для программиста, но эти недостатки меньше, чем при переходе с ассемблера на си, особенно учитывая то, что си остается доступен (имеется в виду переход в своем проекте)

2. по-моему самый серьезный недостаток вида «жри что дают и не выпендривайся» — это c++ ABI (в широком понимании) — манглинг, __gxx_personality_v0, формат указателя на члены класса, формат vtable и т.п. (да, это сковывает свободу выражения мыслей, но все же на практике можно жить без этого)

3. а вот на практике: при использовании плюсовых библиотек вместо сообщения об ошибке часто могут вываливаться кишки библиотеки, которые разбирать и понимать бесполезно (с точки зрения затрат времени); справедливости ради — в си тоже похожее иногда может быть, если некая фича реализована макросами или об ошибке сообщает линкер (а не компилятор), но там масштаб проблемы куда меньше; впрочем, если начнут использоваться новые фичи си (позволяющие использовать в макросах информацию о типах), то си начнет подтягиваться к с++

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

к примеру, даже если использовать с++_без_классов_и_исключений, то все равно это лучше чем си в том смысле, что вместо опасного кода

#define LENGTH(array) (sizeof(array)/sizeof(array[0])) 

можно использовать безопасный

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

и, пожалуй, самое гнусное: допустимость реализаций с GC. начиная с С++11 зашёл разговор о GC и даже о «strict pointer safety» (у меня нет приличных слов, чтобы это перевести на русский язык). и это принципиальная проблема. если стандарт опустился до такого, то дальше я не знаю, что будет.

я не знаю, что у них там получится; вопросы в том, что:

1. нужно ли будет платить за GC, если ты его не используешь (платить скоростью исполнения программы и временем разработки)

2. можно ли будет специализировать GC под свою задачу

если ответы на эти вопросы «нет, да», то сложный рантайм (я о GC) — это благо, а не вред

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от clover

GC как раз очень сомнительная фича

GC нужен (см. вопросы 1 и 2 выше), но че у них получится я не знаю

update: по крайней мере язык должен позволять подключить свой GC так, чтобы не пришлось чесать репу и думать «а что если где-нить в регистрах или месте, куда компилятор делает register spilling остались корни для GC?»

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Эдди, верни аккаунт девушке!

Ну да, есть люди, которым нравится вызывать руками деструкторы, выписывать функторы и for'ы, не помещающиеся в 80 символов. Укушенные бейсиком, они думают, что если что-то делается неявно, то это тормозит. До сих пор вспоминаю, как какой-то ассемблерщик (Пирогов?) писал, какой кайф ловит от ручного запихивания параметров функции в стек, и какое зло INVOKE.

Но есть еще люди, которым работу работать, а не самоудовлетворяться или самоутверждаться.

anonymous ()
Ответ на: комментарий от anonymous

До сих пор вспоминаю, как какой-то ассемблерщик (Пирогов?) писал, какой кайф ловит от ручного запихивания параметров функции в стек, и какое зло INVOKE.

нормальный язык должен позволять удобно запрограммировать свой способ запихивания параметров функции в стек

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

1. Зачем?

2. В каком-то языке это есть, или все ненормальные?

3. Си не определяет способ передачи параметров, и даже не требует стека. Реализация же (gcc) дает на выбор несколько calling convention.

anonymous ()
Ответ на: комментарий от anonymous

1. Зачем?

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

2. В каком-то языке это есть, или все ненормальные?

нормальный язык мне неизвестен

3. Си не определяет способ передачи параметров, и даже не требует стека.

вот этот вопрос интересен, над ним стоит подумать, но я попытаюсь ответить сразу

си не дает возможности указать, что эта функция не будет вызываться рекурсивно

а в нормальном языке должен быть атрибут «эта функция не будет вызываться рекурсивно» и поэтому компилятор:

1. вправе делать больше оптимизаций (удалять использование стека)

2. должен давать ошибки на тему «а вот из-за этого функция может быть вызвана рекурсивно»

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

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

Компилятор тоже заботится об эффективности. По крайней мере для static функции он может всё сделать лучшим образом, вплоть до инлайна.

Между единицами трансляции, конечно, сложнее. Тут либо руками расставлять директивы компилятора, либо полагаться на LTO. Либо переходить на язык с JIT :D

в нормальном языке должен быть атрибут «эта функция не будет вызываться рекурсивно»

Fortran forever %)

А вообще трудно представить, чтобы всё это отражалось на производительности. inline хватит всем. Лично мне алиасинг кажется бОльшим злом в плане микрооптимизации - и, кстати, в C++ с ним получше.

anonymous ()
Ответ на: комментарий от eao197

OCaml?

я думаю, что это не тот язык, который стал бы выжимать *такую* производительность; по первой же гуглессылке «ocaml difference let let rec» видим:

With let x = e1 in e2, the binding is only present in e2's environment, while with let rec x = e1 in e2 the binding is present in both e1 and e2's environments.

(Edit: I want to emphasize that it is not a performance issue, that makes no difference at all.)

ну и понятно, что имея ref, можно сделать рекурсивную функцию без let rec; тут я че-то накарябал на эту тему, вроде работает:


let wrong_answer n = 12345 in
let twice = ref wrong_answer in
let right_answer n =
    match n with
    | 0 -> 0
    | x -> 2 + !twice( x-1 )
in
twice := right_answer;
!twice( 21 );;

пишет:

 - : int = 42 

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от anonymous

Лично мне алиасинг кажется бОльшим злом в плане микрооптимизации - и, кстати, в C++ с ним получше.

и что там получше? (но если ты про то, что в с++ можно передать функцию в шаблоне, а в си только указателем, то это не интересно)

Либо переходить на язык с JIT :D

чтобы уж окончательно огорчить Iron_Bug скажу: да, JIT тоже нужен в дополнение к GC (и LTO, но это ее не огорчит)

(правда не такой JIT как в яве... а хороший...)

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от eao197

https://habrahabr.ru/post/308594/

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

class tricky_performer_t: stats_collector_t< external_lock_t< complex_task_queue_t::lock_t, no_lock_at_start_stop_policy_t > >
{ 
   .....  

(возможно без этого нет смысла лепить шаблоны, т.к. все оптимизации компилятор и так сделает)

кроме того параметр шаблона, который принимает no_lock_at_start_stop_policy_t вроде можно сделать enum-ом

з.ы. на швабре меня нет

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

я по диагонали прочел

Так может мне ваш ответ тоже по диагонали прочесть? Ну и сразу вывод — вы не доделали свой комментарий.

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

там красивее будет если из этого сделать микс-ин, т.е.

performer не разумно наследовать от stats_collector-а т.к. performer-у нужно иметь несколько stats_collector-ов внутри (возможно, каждый из них со своим уникальным lock_holder-ом и policies).

А вот stats_collector вполне можно было приватно наследовать от lock_holder-а. Что и было сделано впоследствии, когда появились новые типы performer-ов и им нужны были stats_collector-ы без захвата lock-ов вообще.

eao197 ★★★★ ()
Ответ на: комментарий от www_linux_org_ru

GC нужен (см. вопросы 1 и 2 выше), но че у них получится я не знаю

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

clover ()
Ответ на: комментарий от anonymous

Кому нужна жаба после появления C# версии 4.0? В Шарпе один LINQ чего стоит, а жаба как была тормозным гомном так и остаётся.

и чем же лучше шарп? разнообразием установленных версий .NET framework?

clover ()
Ответ на: комментарий от EXL

без сегфолтов.

Да? А я вот попользовался одним жаба софтом недельку и кучу раз видел сегфолт: тупо падает эта жабамашина без каких либо описаний причин. Чем не сегфолт? Тем что слово «сегфолт» заменили на «завершилась»?

LinuxDebian ★★ ()

чем вызвано массовое увлечение написанием десктопного ПО на java

По пути наименьшего сопротивления... Легче писать - быстрее получается вкинуть свой «высер» и получить бабло. А потом фиксить его в процессе.

LinuxDebian ★★ ()
Последнее исправление: LinuxDebian (всего исправлений: 1)
Ответ на: комментарий от LinuxDebian

По пути наименьшего сопротивления... Легче писать - быстрее получается вкинуть свой «высер» и получить бабло. А потом фиксить его в процессе.

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

clover ()
Ответ на: комментарий от LinuxDebian

По пути наименьшего сопротивления... Легче писать - быстрее получается вкинуть свой «высер» и получить бабло. А потом фиксить его в процессе.

Но ведь это лучше, чем годами проповедовать «канонические» способы создания ПО на «настоящих» языках программирования, используя «настоящие» всякие прочие ООП, policy design, MVC и т.д. (тысячи их) :-) При этом, не имея денег, скажем, на придание зубам настоящей белизны голливудской улыбки :-) Или на покупку жене новой шубы :-) Или на покупку новых джинсов себе :-) Или лучше без штанов с жёлтыми зубами проповедовать Ъ-путь Ъ-разработчика? :-)

anonymous ()
Ответ на: комментарий от clover

Ну... Работодатели агитируют студентов, а им лень учить что-то еще... А на чем ты будиш писать домашний проект если у тебя уже «жаба головного мозга»???

LinuxDebian ★★ ()
Последнее исправление: LinuxDebian (всего исправлений: 2)
Ответ на: комментарий от LinuxDebian

Ну... Работодатели агитируют студентов, а им лень учить что-то еще... А на чем ты будиш писать домашний проект если у тебя уже «жаба головного мозга»???

но ведь никому вот в голову не приходит на биндингах Qt к матлабу писать панельный менеджер, чем java хуже?

clover ()
Ответ на: комментарий от clover

eclipse, Netbeans, PyCharm и тд на java

3 с половиной ИДЕ для Джавы написанные на Джаве. Ого. Почти весь десктопный софт.

Ну и еще какие-то монструозные энтерпрайзные приложения, которые написанные на Джаве только потому, что Джава модная нынче в энтерпрайзе (потому что дешево).

Предлагаю считать тему закрытой.

sphericalhorse ★★ ()