Странный C++

Интересно, если успевают вот эти ребяты с кодированием, передачей, и декодированием. То на cpu и java успеет? Как думаешь? Или всерьёз станешь утверждать, что вылеты которые даёт ping -c 10000 до самого себя но через инет в твоём компе будут ниже, чем времена сборки мусора даже для пары тысяч объектов?

Лаг и убогую картинку в текущих реалиях пофиксить нереально.

И при чём тут GC к стримингу? Если речь про мифический, ультрабыстрый GC для Java/C# - это прекрасно. Но воз и ныне там.

К тому, что посчитать накладные расходы на GC надо для начала(это десятки микросекунд при тонкой настройке, даже для систем которые по 10к сообщений в секунду переваривают, каждую секунду а не через i/o буффера и начинают загибаться при постоянной нагрузке). А потом вспомнить, что просто не RT планировщик любой твой нативный код в настольной системе может на пару миллисекунд отправить покурить в любой момент времени. А как показывает практика, это может быть и не пара миллисекунд - легко, особенно если играть параллельно с запущенным браузером или ещё чем то, что время от времени утилизирует проц.

О чём и речь. Люди посчитали, и решили что не подходит. Мне без разницы на чём написаны игры, главное чтобы не тормозили. Если это будет C#/Java - пожалуйста.

Но примеров AAA игр на C#/Java я не знаю. Поэтому ваши примеры не более чем спекуляции.

Что бы оценить написанное мной выше - напиши простой бенчмарк на любимом твоём быстром нативном языке.

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

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

10к замеров будет показательно вполне. Посчитай потом медиану и распределение. Посмотри на результаты, и подумай, стоит ли 100-200us потратить на сборку мусора раз в контролируемый тобой промежуток времени в системах где время отклика 1-5ms уже упирается в возможности железа(заявленное время отклика дисплеев).

Потом напиши наивный вариант на java. Сравни, посмотри на график задержек, большие пики которые ты увидишь, это скорее всего переключения контекста. Если пиков не увидишь, можно увеличивать время итераций пока на графике задержек не начнут появляться пики. Пики одинаковой величины - скорее всего будут переключениями контекста, а пики поменьше будут результатами работы дефолтного аллокатора или gc.

Тестировать hello world то ещё бред. Да и тестировать синтетику тоже смысла нет.

Нужен полноценный продукт, который можно оценивать.

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

В си++ не должно быть сборки мусора

Какое-то странное сектанство. Множество lock-free контейнеров используют GC на основе hazard pointers. И это внезапно увеличивает производительность, а не уменьшает.

Но примеров AAA игр на C#/Java я не знаю

Ну, не знаю что насчет ААА, но давненько в моей молодости была игра Chrome от поляков из Techland, по сути одна Java была. А это компьютеры были не те, что сейчас.

вижу что ты только трепаться готов

Вбрасываете вы, а не я.

Ты вообще ничего содержательного не пишешь. Как обычно.

В си++ не должно быть сборки мусора

Какое-то странное сектанство. Множество lock-free контейнеров используют GC на основе hazard pointers. И это внезапно увеличивает производительность, а не уменьшает.

Зато у остальных уменьшает. У C++ полно применений, где lock-free контейнеры не используются совсем. И даже lock-free контейнеры можно реализовывать без hazard pointers: https://aturon.github.io/blog/2015/08/27/epoch/

Мне друг рассказывал, как они в одном известном банке у софтины на Java, которая торговала на бирже, тупо отключали GC и деплоили на сервер с тонной RAM. Потому что GC паузы задолбались профилировать по задержке. В их случае торговая сессия была ограничена по времени и памяти ровненько хватало до конца дня.

tl;dr зачем сравнивать теплое с мягким?

У C++ полно применений

В HW они не используются, я не спорю. Но есть HP решения, в которых они активно используются. И в них используется GC. И используются такие структуры данных как раз для увеличения провизводительности.

можно реализовывать без hazard pointers

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

И смешение C++ и GC в том отдельном примере с контейнерами вместе с Java, в которой GC by design - непонятно зачем. В роботах тоже Java по этой причине не принята. Не надо ее там использовать. Значит ли это, что где-то в них нельзя использовать shared_ptr? Можно и используется внутри ROS, при генерации заголовочников типов сплошь и рядом.

Так в итоге, в синтаксисе C++ зачем сборщик мусора, если кому надо GC прекрасно и существующими решениями обходятся?

Что значит «в синтаксисе»? std::shared_ptr - это в синтаксисе или нет? Что в синтаксисе Java кроме объекта gc является «в синтаксисе»? Искренне не понимаю.

Кроме того, философия плюсов «плати только за то, что используешь», так что под дулом винчестера никто стоять над духом не будет, приказывая использовать GC. Тем более, что сторонними библиотеками их и так навалом.

По моим наблюдениям, нормальных людей нет. Дай людям этот ублюдочный кусок крышечноо говна, и они начнут писать на нём логику. Лучше вообще с этим не связываться и брать P/Invoke сразу.

Я видел случай когда сей подход сравнивался относительно pinvoke с бенчмарками(как по количеству кода так и собственно по накладным расходам) и шоукейсами перед принятием решения о выборе инструмента.