Реальные минусы Vulkan?

А Bedrock версию проф прогеры, а вот что значит проф?

С опытом в оптимизацию в контексте геймдева. Там вообще другая архитектура, их некорректно сравнивать.

Давай не будем в сотый раз спорить про перф java vs c++, есть херова гора тестов, почитай.

Тесты бывают разные, вот например С++ сливает C# и SBCL, я на Java переписывал пример, он выигрывал у всех трех. Нужно посмотреть на свойства двух языков, как исполняется код, я вот не вижу причин для того что бы Java в несколько раз тормозила в среднем. Примеры очень по разному можно написать.

Тесты бывают разные Garnet - кэш от Microsoft, написан на C#, делает и Redis, и Dragonfly (комментарий)

Да, один хитровы*****ый (или просто незнающий плюсы) написал херню на плюсах и гордо заявил, что они медленнее. А когда пример исправили, все начали петь, что это очень сложно и нужно сравнивать наивный код. Как обычно куча оговорок.

Там не было исправления, показывался пример работы с множеством независимых объектов чье время жизни определяется во время работы, что очень похоже на игры. Пример который появился позже имеет совсем другую логику и не может считаться «исправлением», это просто другая программа, объекты в нем не могут жить по отдельности, а находятся в едином векторе, ты бы хотел что бы все сущности в твоей игре, один раз попав в вектор, больше никогда не выгружались?

Короче вывод: тест на плюсах должен быть написан через жопу, т.е. «правильно», и тогда он покажет «правильный результат», а иначе это, вы все, плюсовики, неправильные тесты пишите.

• а почему это правильно так делать?
• да потому что иначе они слишком быстрые получаются

С опытом в оптимизацию в контексте геймдева

Вовсе не факт, что они этот опыт применяли в полной мере. Сроки, продакт менеджеры, все дела…

Не всем дано думать, понимаю. Кстати, а ведь можно сказать наоборот, что тест был исправлен в C# версии. Как тебе такое?

Можно просто изменить условия задачи, и тогда в С++ не выйдет использовать вектор, тебе не хватает понимания о чем тест вообще, иначе бы ты интуитивно понял что не так. Например можно подавать на вход файлы, с заданием распределять объекты на группы, и потом из нескольких групп создавать подгруппы, после чего по списку из id удалять их.

Так же можно переписать пример как в С++ варианте #2 и на Java, C#, но тогда пропадет весь смысл, кстати в таком варианте Java тоже оказывается быстрее.

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

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

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

Это везде применимо, потому что объекты игры я загружу заранее, потом преаллоцирую с запасом массив ссылок на эти объекты + координаты, а уже потом «в открытом мире» будут заполнять преаллоцированный массив ссылками на объекты с координатами в рамках текущего сегмента впопенворлда. Эпизодически проверять смену сегмента и обновлять массив ссылок по необходимости. Это типовая схема реализации «уровня без границ» - никакой дурак не пытается «всё-всё-всё» хранить в памяти, и предзагрузка данных + отсев не нужных данных - это нулевой уровень обучения геймдеву.

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

В работе реального ПО расходы на аллокацию / освобождение памяти в сравнении с расходами на остальные операции обычно совершенно не значительны. В случае с играми - так вообще меньше 1%.

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

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

Лет 15-20 назад подтормаживания родного явовского AWT на обычном GUI были видны невооружённым глазом.

Это везде применимо, потому что объекты игры я загружу заранее

Что есть объекты игры? Текстур и моделей в GTA V более 50 гб. Как ты ее будешь запускать на компьютере с 4 гб памяти?

В работе реального ПО расходы на аллокацию / освобождение памяти в сравнении с расходами на остальные операции обычно совершенно не значительны.

Я с этим и не спорил.

Ява может в целом прекрасно работать, пока речь идёт о байтах в её памяти.

Java может работать с байтами и не в своей managed памяти.

Лет 15-20 назад подтормаживания родного явовского AWT

Они видны и сейчас на любом компьютере.

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

Тест показывает что нормальный GC лучше чем его костылизация через подсчет ссылок, и это реальная проблема, Rust как язык вообще на этом построен, и его пользователи часто уверены что никакого GC там нету, и вся проблема решается статически. GC это встроенная возможность Java, умные указатели С++. Можно в С++ реализовать GC, и в любом языке можно сначала собрать нативный код и сделать к нему jmp, и что тогда сравнивать?

Ладно, тебе тест не нравится, какие по твоему свойства Java не позволяют ей нормально работать по сравнению с С++?

Тест показывает что нормальный GC лучше чем его костылизация через подсчет ссылок, и это реальная проблема

Какой был мой тезис?

Тебе лучше знать, ты говорил мне посмотреть тесты, я тебе вот тест показал, тебе что то сразу не понравилось.

Я тебе не говорил смотреть подлоги вместо тестов.

Ладно, тебе тест не нравится, какие по твоему свойства Java не позволяют ей нормально работать по сравнению с С++?

Ява нормально работает, но менее производительный и более ресурсоемкий по сравнению с плюсами. Что тут обсуждать?

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

По мне ощутить и заметить вполне можно.

ты бы хотел что бы все сущности в твоей игре,

Что есть объекты игры?

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

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

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

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

Я говорил про то что невозможно загрузить все сразу,

Нет, это я про это говорил. А ты со мной спорил:

Это не везде применимо,

На что я тебе объяснил, что не только «везде применимо», а вообще только так и делают.

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

Умничка, ты правильно понял концепцию memory pool’а.

это тоже самое, только вместо кучи массив.

Это совсем не то же самое, как по времени доступа, так и по потреблению памяти. Именно по этому их используют в играх примерно всегда. Даже если школьник пишет игру на «игровом движке», движок у себя под капотом будет работать по этой схеме.

Иными словами из всех видов приложений с большим объёмом вычислений и потреблением памяти грамотно написанные игры - наименее заинтересованные в случайном выделении произвольных участков памяти на куче.

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

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

Прости, я переоценил твою возраст^W квалификацию^W способность прочитать и понять написанное:

грузят ту часть, которая нужна на этот уровень
преаллоцированный массив ссылками на объекты с координатами в рамках текущего сегмента впопенворлда. Эпизодически проверять смену сегмента и обновлять массив ссылок по необходимости. Это типовая схема реализации «уровня без границ»

Memory pool
какой элемент нужно освободить

И нет, ты не понял, что такое мemory pool.

А, ты хочешь сразу весь memory pool при заполнении освобождать, и потом грузить 95% того что только что удалил, идея потрясающая.

Или ты хочешь загрузить сразу 50 гб ресурсов?

Что из двух? Определиться можешь наедине, мне это надоело.

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

Потому что ты - говнокодер, сравнивающий какие-то там синт. тесты :P

Сделай там и там ынтерпрайз архитектуру в 10 слоёв с библиотеками и потом сравнивай.

Какой был мой тезис?

Тебе лучше знать

АХАХАХАХА. ЛОЛ.
Морковка, не ходи на лор, переписывайся лучше со стенкой.
«Какой тезиз? Откуда я знаю какой у тебя тезис. Делать мне нечего, сообщения твои читать.» КЕК.