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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

десктопного ПО на java

где? web везде и это правильно

Фактов не будет? Просто еще одно анонимное чмо решило раскрыть рот только потому, что с анонимного чмо спроса нет.

хаха, походу я оказался прав, за живое видимо задело :)

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

В чем бред? А то тут люди зарабатывают на этом и не в курсе...

В чем бред? А то тут люди зарабатывают на этом и не в курсе...

в первую очередь я имею ввиду сделать весь десктоп через браузер

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

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

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

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

А win10 декстоп? https://developer.microsoft.com/en-us/windows/bridges/hosted-web-apps Они ведь туда же...

А win10 декстоп? https://developer.microsoft.com/en-us/windows/bridges/hosted-web-apps Они ведь туда же...

и? это же не массовая киллер-фича. html-десктоп и в win98 был, и где оно сейчас?

ухудшилось:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Зачем?

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

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

1. Зачем?

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

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

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

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

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

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

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

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

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

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

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

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

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

Fortran forever %)

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

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

OCaml?

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 

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

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

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

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

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

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-ом

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты тролль.

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

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

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

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

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

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

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

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

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

Я что сказал что это плохо или хорошо? Мне вообще пофиг...

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

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

eclipse, Netbeans, PyCharm и тд на java

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

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

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

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

не только для Java же, почти для всех языков есть на яве

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

Вот и для GNU/Linux программы в существующих DE нужно переписывать на HTML5/CSS/JavaScript, конечно.

Вон, в MS переписали огромное количество компонентов этой вашей дисяточки на C#

Есть информация, что именно там на C# переписано? Как-то стало интересно, а ничего нарыть не могу, винда такая винда. Или ты просто вангуешь?

Ну вот, например, Visual Studio давно уже переписали на C#:

https://www.quora.com/As-of-2015-how-much-of-Microsoft-Visual-Studio-is-writt...

Новый диспетчер задач, новый Explorer.EXE, оболочка браузера EDGE и куча другого винософта имеет в зависимостях библиотеки .NET.

Новый диспетчер задач, новый Explorer.EXE, оболочка браузера EDGE и куча другого винософта имеет в зависимостях библиотеки .NET.

Так они действительно написаны под .NET, или просто имеют биндинги к .NET?

С++ — ненужное зло! Все задачи можно решить обычным C89!

И, в отличие от кода на крестах, сишный код может читать любой человек без желания сблевать!