DGenPACK: обновления/обсуждение

[NB79]

Немного оффтопа о многопоточности и многопроцессорности. А есть ещё и распараллеливание вычислений, это вообще немножко третье. Когда кто-то начинает говорить о многопроцессорности, то всегда надо просить его уточнить что конкретно говорящий имеет ввиду.

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

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

Параллельно мы смотрим на ядра, сейчас уже можно планировать исходя из допущения, что ядер у нас всегда будет больше одного. Есть два принципиально разных подхода к планированию нагрузки на ядра, один обеспечивает максимально быстрый отклик на входящие события, второй - максимальную загруженность ядра. Из этого понятно, что тут основная сложность в выборе оптимального баланса отдельных частей нашего приложения. Если о графике для примера, то для максимальной производительности одно ядро должно быть постоянно занято подготовкой данных для видео адаптера, но оно всё равно будет значительную часть времени недогружено, ибо сцена может меняться не достаточно динамично. И у нас может появиться соблазн подкинуть на это ядро ещё каких-то потоков, чтоб "не простаивало". А потом, вруг! , при эксплуатации в какие-то моменты у нас резкие просадки производительности начинают вылезать, хотя сцену мы строили исходя из данных профилёра. На этом этапе и в этой части рулит правильный выбор изначальной стратегии и качественное, всеобъемлющее тестирование результата.

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

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

Как-то так.

[carsmaster]

Сообщение от NB79

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

Может не так развернуто, но именно это я и имел ввиду.

Можно аналогию привести, например с облицовка ванной плиткой кафельной. Если изначально не продуманна "стратегия" и не просчитана правильно раскладка плитки в голове и на бумаге (например я дилетант-заказчик говорю мастеру : "ложи вот так и все тут") , то что потом удивляться что плитка смотрится ущербно и косо-криво-неравномерно......
Так и с потоками-ядрами, не выработал изначально правильную "раскладку плитки", то никакое многоядерное железо(хоть 100 ядер) не вытянет и получим "тормоза" периодически....
Имено с этим как основные трудности я и связываю даже сейчас в 2019 году.
Так что многоядерность в "кривых" руках-мозгах ничего не дает....

Сообщение от NB79

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

Ну так я об этом и написал, только короче : "надо все с нуля писать" и без тормознутой джавы. Имелось ввиду, что джаву переписывать не в смысле просто "поменять местами буквы", а именно убрать медленную джаву из "быстрых" мест....
А это значит что "все с нуля" в нашем случае.

И я думаю никто не ответит на вопросы:

1. ФИО, должность, команда, организация ??
2. Кто возьмется и главное сделает это ???

Так что в реальности будем с этим жить и использовать "обходные маневры" где можно и где нельзя.
И пусть даже они выглядят как : "Почесать правой рукой левое ухо"...

[carsmaster]

Сообщение от Toobone

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

Есть в игре такой файл .preload, он рулит начальной загрузкой кое-чего.
Расширяя его можно чуть уменьшить тормоза при появлении новых объектов.

Но тут очень тонкая грань между переполнением памяти "предзагрузкой" и достаточной загрузкой памяти.

Имея памяти например 64Гб, можно чувствовать себя чуть свободнее, но какой процент летающих в ИЛ-2 имеют памяти 32 или 64Гб ??

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