Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Потянет твоя Ява пересчитывать такое на лаптопе в реальном времени?
SVZ>Под "пересчитывать" я подразумеваю не только рисование, но и обработку данных (передвинули компонент — трассы переложить, полигоны перезалить, нарушения найти/посчитать и т.д.).

Я на яве программирую больше 10 лет. И в целом часто ковыряюсь с производительностью. Могу так сказать:

По скорости хороший код на яве будет отставать от хорошего кода на C++ в полтора-два раза. Могут быть нюансы с векторизацией. Но в целом примерно такой порядок.

По памяти жава её жрёт как не в себя, по крайней мере по меркам С++. Тут никаких чудес нет.

Ещё есть нюанс с латентностью. Сборщик мусора может остановить поток или всю программу на несколько десятков миллисекунд (а то и сотен). Современные сборщики мусора стали довольно хороши, но за счёт того, что жрут ещё больше памяти. Поэтому в целом можно пытаться даже 60 FPS со сложными расчётами.

Я не знаю, как твой код на С++ работает, какой у него запас. Но примерно можно рассчитывать на то, что жава будет работать не более чем в 2 раза медленней и если нет требований к латентности и этого хватает, то её можно использовать.

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

При обработке больших данных вероятно придётся писать не-идиоматичный код. Всякие int[] и подобное. Но это не так уж страшно. В светлом будущем это планируется улучшить, добавив value-классы.

Здравствуйте, netch80, Вы писали:

SVZ>>Код — без слёз не взглянешь, зато у компании миллиардные годовые обороты.

N>Насколько качество кода влияет на результат тут? Возникают ли от этого, например, трудноуловимые баги?

N>Является ли нормальной политикой, что их код регулярно шлифует спец по языку? (хотя бы до уровня нормального 11-го?)

Когда я там работал никто код не шлифовал. Никакого рефакторинга или ревью не проводили.
Периодически появлялись баги, типа обращения к нулевому указателю или к убитому объекту. Но тогда такую багу вешали на кого-то молодого, вроде меня, её находили и совместными усилиями фиксили.

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Периодически появлялись баги, типа обращения к нулевому указателю или к убитому объекту. Но тогда такую багу вешали на кого-то молодого, вроде меня, её находили и совместными усилиями фиксили.

Цитирую:

SVZ> разработку автотрассировщика, Signal/Power Integrity, практически полностью состоит из физиков, которые худо-бедно освоили "Си с классами".

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

Не нужно приводить доводы, что шейдеры похожи на C++- там нет альтернативы. Или код в ядре. Я сейчас говорю про прикладной софт. И несомненно, разводчик плат, которому нужна юзерская винда для работы- это прикладной софт.

Здравствуйте, vsb, Вы писали:

vsb>Ещё есть нюанс с латентностью. Сборщик мусора может остановить поток или всю программу на несколько десятков миллисекунд (а то и сотен). Современные сборщики мусора стали довольно хороши, но за счёт того, что жрут ещё больше памяти. Поэтому в целом можно пытаться даже 60 FPS со сложными расчётами.

vsb>Я не знаю, как твой код на С++ работает, какой у него запас. Но примерно можно рассчитывать на то, что жава будет работать не более чем в 2 раза медленней и если нет требований к латентности и этого хватает, то её можно использовать.

Это же не VoIP, где неожиданная задержка может разорвать соединение. Здесь важна общая производительность. Скорости много не бывает.
Мы и на плюсах постоянно занимаемся ускорением алгоритмов — задачи непрерывно растут в объёмах.
Поэтому пессимизация в два раза может огорчить

vsb>При обработке больших данных вероятно придётся писать не-идиоматичный код. Всякие int[] и подобное.

Это получится превращение явы в си. Об этом я Тёме и писал. Можно, но зачем?

Яву нужно использовать там, где она сильна — высокоуровневые серверные куски.

Здравствуйте, Тёмчик, Вы писали:

SVZ>>Периодически появлялись баги, типа обращения к нулевому указателю или к убитому объекту. Но тогда такую багу вешали на кого-то молодого, вроде меня, её находили и совместными усилиями фиксили.

Тё>Цитирую:
Тё>

SVZ>> разработку автотрассировщика, Signal/Power Integrity, практически полностью состоит из физиков, которые худо-бедно освоили "Си с классами".

Иии? Есть противоречия?

Тё>После 2010 наверное, в C++ остались лишь религиозные фанатики, усложняющие себе и коллегам по языку, жизнь.

Помимо фанатиков осталось стотыщмильонов проектов, которые нужно поддерживать и развивать.

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

Тебя услышали лет 14 назад и запустили с нуля проект сапра печатных плат на шарпе. DeltaDesign.
Кому-то из здешних камрадов даже довелось поработать в нём. Так как я знаю эту кухню изнутри, то охарактеризовать могу анекдотом:

На свадьбе один из гостей произносит тост:
"Я не знаю невесту, поэтому не могу поздравить жениха, но я хорошо знаю жениха, поэтому не могу поздравить невесту!"

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Это получится превращение явы в си. Об этом я Тёме и писал. Можно, но зачем?

Ну почему в C. Это можно использовать грубо говоря в каком-то самом ядре. А поверх этого можно накрутить какие-то абстракции. Ну и прочие плюсы явы никто не отменял, как минимум — программа никогда не будет портить стек. От явы с массивами до С далеко.

Здравствуйте, vsb, Вы писали:

SVZ>>Это получится превращение явы в си. Об этом я Тёме и писал. Можно, но зачем?

vsb>Ну почему в C. Это можно использовать грубо говоря в каком-то самом ядре. А поверх этого можно накрутить какие-то абстракции.

Да, с этим соглашусь.

vsb>Ну и прочие плюсы явы никто не отменял, как минимум — программа никогда не будет портить стек. От явы с массивами до С далеко.

Хе, аккурат на этой неделе напоролись на переполнение стека.
Пришли корявые данные — граф с циклами, которых не ждали, и рекурсивный алгоритм гикнулся.

Тё>Сразу писать нужно было на C++ или C- что было тогда актуально. Сейчас C++ не актуально, т.к. дорого в поддержке, и другие инструменты появились.
Тё>Ок. Но тв не ответил, чем эти остпльнве задачи пиинципиально требуют C++ — ибо что я вижу, это "ниасилили" другие языки.

Кстати, Темыч, а ты на с#/дотнете сейчас программируешь? Тут в соседней теме говорят, что С# скоро перегонит по сложности плюсы http://rsdn.org/forum/flame.comp/8183400.flat

Автор: Shmj
Дата: 29.01.22

Известный факт: уже в версии 3.0 спека C# была раза в полтора толще спеки С++.

Согласен с этим?

Здравствуйте, Stanislav V. Zudin, Вы писали:

Тё>>Цитирую:
Тё>>

SVZ>>> разработку автотрассировщика, Signal/Power Integrity, практически полностью состоит из физиков, которые худо-бедно освоили "Си с классами".

SVZ>Иии? Есть противоречия?
Да. Например, когда я привел когда-то здесь код, мне обосновали, что я лох педальный ибо нужно move semantics. Даже когда я кодил на плюсах, я сам устравал срачи про буст lex или как его. Потом с уходом в жаву, попустило.

SVZ>Помимо фанатиков осталось стотыщмильонов проектов, которые нужно поддерживать и развивать.
Я хз, не вижу никаких проектов, которые хотелось бы поддерживать и развивать. Ибо если это винапи, мфц или переписанное на qt десктоп- сразу закопать.

SVZ>Тебя услышали лет 14 назад и запустили с нуля проект сапра печатных плат на шарпе. DeltaDesign.
SVZ>Кому-то из здешних камрадов даже довелось поработать в нём. Так как я знаю эту кухню изнутри, то охарактеризовать могу анекдотом:

SVZ>

SVZ>На свадьбе один из гостей произносит тост:
SVZ>"Я не знаю невесту, поэтому не могу поздравить жениха, но я хорошо знаю жениха, поэтому не могу поздравить невесту!"

Хаха. С шарпом у меня был скорее печальный опыт. Хотя, Typescript и нод на нем- замечательная, приятная вещь.

SVZ>Обрати внимание, что даже на фэншуйном шарпе, а не богомерзком с++, на разработку ушло больше десяти лет и до сих пор проект не в самом своём лучшем состоянии.
Потому, что виндовз онли шарп. Я против этого.

Здравствуйте, vsb, Вы писали:

vsb>Какие знания позволят "не конкурировать с мартышками" (оставаясь в го)? Например знания фуллстака (кубер, постгрес, тайпскрипт, реакт)?

Как по мне так достаточно не быть чисто Go разработчиком. Обычно я видел Go в связке с Python, C++ и даже Elixir. И, кстати, я так же не разу не видел требования фуллстека от Go разрабов, обычно это чисто бэкенд в той или иной форме.

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

Здравствуйте, Тёмчик, Вы писали:

Тё>А может быть, засилие сектантов-бдсмщиков в C++ как раз причина "потратит несколько недель на решение задачи"? Ибо потратит не на решение задачи вычислительной геометрии, а на борьбу с языком C++.

один и тот же комп может обработать одновременно 4 видеопотока в HD качестве на java
или 20+ потоков на С++

комп стоит от 3 тыс $ можешь почитать сколько экономит заказчик

Здравствуйте, sergey2b, Вы писали:

Тё>>А может быть, засилие сектантов-бдсмщиков в C++ как раз причина "потратит несколько недель на решение задачи"? Ибо потратит не на решение задачи вычислительной геометрии, а на борьбу с языком C++.

S>один и тот же комп может обработать одновременно 4 видеопотока в HD качестве на java
Жава создаёт временные объекты?

S>или 20+ потоков на С++
С intrinsic ами?

S>комп стоит от 3 тыс $ можешь почитать сколько экономит заказчик

Скорее всего, вы неправильно готовили, ну ещё другое определение, кому яйца мешают. В первую очередь минимизировать нагрузку на GC, и использовать C-е интринсики, закидывать достаточно крупные куски данных в нативный векторизованный код (т.к. JNI вызов дорогой).

Если наивно писать, то у вас и C++ будет в 2 раза медленнее, чем могли бы.

Здравствуйте, Артём, Вы писали:

Аё>Скорее всего, вы неправильно готовили, ну ещё другое определение, кому яйца мешают. В первую очередь минимизировать нагрузку на GC, и использовать C-е интринсики, закидывать достаточно крупные куски данных в нативный векторизованный код (т.к. JNI вызов дорогой).
Артёмка, если на жабе старательно вышивать чтоб получалось как на С то проще уж сразу взять С++ и избавиться от головняка "как не дать жабе быть жабой"

Здравствуйте, CreatorCray, Вы писали:

Аё>>Скорее всего, вы неправильно готовили, ну ещё другое определение, кому яйца мешают. В первую очередь минимизировать нагрузку на GC, и использовать C-е интринсики, закидывать достаточно крупные куски данных в нативный векторизованный код (т.к. JNI вызов дорогой).
CC>Артёмка, если на жабе старательно вышивать чтоб получалось как на С то проще уж сразу взять С++ и избавиться от головняка "как не дать жабе быть жабой"

На самом деле, C++ не нужен в связке где есть Java, если только нет задачи прицепить либу на C++ в нативный код на C. Golang + либа на C с интринсиками ещё лучше, на go всё готовое из коробки для микросервисов- как и Java, только в 10 раз меньше букв.
C++ это боль. Просто по стоимости разработки и поддержки, поиска трудноуловимых прострелов в ногу. Считая по человекочасам на фичу. Я пишу с позиций распределённого приложения. Для десктопной апликухи может быть по-другому, но их в наше время никто не пишет (исключения- браузер Chrome и т.п сами по себе платформы для испольнения прикладного софта).

Здравствуйте, Артём, Вы писали:

S>>один и тот же комп может обработать одновременно 4 видеопотока в HD качестве на java
Аё>Жава создаёт временные объекты?
S>>или 20+ потоков на С++
Аё>С intrinsic ами?

Да ладно, кодеки никто сам писать не будет, эта часть будет общая.
На плюсах можно написать такой код, где не будет лишних копирование и выделений памяти, лишней конвертации и т.д. Если взять видео, то можно представить, какие это огромные массивы данных каждую секунду.
Чистый С в этом плане мне не нравится. Можно посмотреть на тот же ffplay.c, сколько там тысяч строк кода и сколько кода в принципе лишнего. Я как-то переписывал ffplay на С++, чтобы разобраться с ffmpeg и сделать быстрый декодинг и отображение видео. Объем кода очень сильно сократился.

LVV>Мой ответ: а на каком вам нужно? На том и буду писать.

Ну, всё-таки "переключение" на другой язык (привыкание к новому синтаксису, изучение библиотек) требует времени. И не каждый наниматель готов ждать пока работник "переключится".

Здравствуйте, Nuzhny, Вы писали:

N>Да ладно, кодеки никто сам писать не будет, эта часть будет общая.
Вот именно.

N>На плюсах можно написать такой код, где не будет лишних копирование и выделений памяти, лишней конвертации и т.д.

На Java можно написать такой код, где не будет лишних копирование и выделений памяти, лишней конвертации и т.д. Mmap и flyweight pattern спасут отца русской демократии.


N> Я как-то переписывал ffplay на С++,
Велосипедизм- один из худших пороков C++.

Здравствуйте, Артём, Вы писали:

Аё>На Java можно написать такой код, где не будет лишних копирование и выделений памяти, лишней конвертации и т.д. Mmap и flyweight pattern спасут отца русской демократии.
Вот только нафига тогда вообще жаба?

Здравствуйте, Артём, Вы писали:

N>>На плюсах можно написать такой код, где не будет лишних копирование и выделений памяти, лишней конвертации и т.д.
Аё>На Java можно написать такой код, где не будет лишних копирование и выделений памяти, лишней конвертации и т.д. Mmap и flyweight pattern спасут отца русской демократии.

Именно поэтому на Java нет ни плееров, ни видеосерверов? Именно поэтому что Nvidia, что Интел, что АМД начинают новые проекты на С++?

N>> Я как-то переписывал ffplay на С++,
Аё>Велосипедизм- один из худших пороков C++.

А как ещё изучить тот же ffmpeg? У них есть примеры на все случаи жизни, но по ним получается медленней, чем в ffplay. Мне кажется, что разбирать исходники готового ПО — это лучший способ изучения технологии.

Здравствуйте, Nuzhny, Вы писали:

N>Именно поэтому на Java нет ни плееров, ни видеосерверов?
Есть.

N>Именно поэтому что Nvidia, что Интел, что АМД начинают новые проекты на С++?
В облаках C++ нет.

N>>> Я как-то переписывал ffplay на С++,
Аё>>Велосипедизм- один из худших пороков C++.

N>А как ещё изучить тот же ffmpeg?
Чтением документации?

N> разбирать исходники готового ПО — это лучший способ изучения технологии.
Разбирать исходники клиентского кода вместо чтения документации- извращение.