Elite Games - Свобода среди звезд!
.
ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!

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

Поиск | Правила конференции | Фотоальбом | Регистрация | Список пилотов | Профиль | Войти и проверить личные сообщения | Вход

   Страница 4 из 5
На страницу: Пред.  1, 2, 3, 4, 5  След. | Все страницы
Поиск в этой теме:
Канал Игры Мечты: «Два пути - количество или качество игр»
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Sh.Tac. :
вширь или вглубь?

Совершенно верно.

Sh.Tac. :
от некоторых затратных идей

А можно пару примеров идей?
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 16:54 29-09-2015   
Sh.Tac.
 151 EGP


Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426

Зарегистрирован: 27.07.2005
а это почти всё что должно быть в игре мечты Улыбка
взять хоть глобальную экшн-стратегию где смешались "кони-люди", по сети такое передавать, любая сетка нагнётся

более того, попытки сделать влобную стратегию с использованием сети UE4 также быстро наталкиваются на то, что сеть заточена под другое, имеющихся механизмов управлением репликацией недостаточно, грубо говоря сервер не может запомнить слал он что-то определённому клиенту или нет, и продолжает спамить всем
_________________
This is what you get ...
(c) Radiohead
    Добавлено: 17:53 29-09-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Diff :
Методы решения - укрупнение блоков памяти и, по возможности, отказ от постоянного выделения-освобождения вообще - тоже придуманы не вчера. Эти в огромном количестве выделяющиеся блоки (в случае ТБС, как я понимаю, это блоки обсчета 100500 веток вариантов) как правило однотипные - так и нефиг гонять их туда-сюда, создай сразу пачку и дальше только подгружай в них новые данные.

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

У Джонатана следующие примеры.

1. Создаем например объект-пул. В нем сразу резервируем 64К. Выделение памяти в пуле делается как на ленте, т.е. быстро. Удаляется из пула только все сразу целиком. Т.е. тоже быстро.
Например, в игре герой зашел на экран. Сделали ему пул. Вышел на следующий экран - грохнули пул и создали все снова, но для нового экрана.
В случае по умолчанию глобальных new/delete malloc/free получаем дефрагментацию и тормоза для выделения и освобождения.

2. Создаем пул, только non-thread-safe. И выдаем каждой нити свой пул. Как результат, во время new/delete malloc/free менеджер памяти не должен синхронизироваться с другими нитями, соответственно использовать mutex и т.п.. Как следствие, возрастает производительность для многопоточных систем.

В случае его TBS соображения такие. Если много AI, и запустить их многопоточно, то они будут конкурировать друг с другом, т.е. им поможет пункт 2. Если AI использует для решения малый объем информации, то этот объем можно засунуть в отдельный для него малый пул. И соответственно, получаем преимущество кэша процессора и пункта 1 (например если нужно решать постоянно задачу обхода дерева решений, где при возврате нужно чистить нижеотбрасываемую инфу по дереву).
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 02:06 18-10-2015   
Diff
 708 EGP


Модератор
Рейтинг канала: 2(11)
Репутация: 44
Сообщения: 4179
Откуда: Сферическая Земля в вакууме.
Зарегистрирован: 04.07.2003
Minx :
Например, в игре герой зашел на экран. Сделали ему пул. Вышел на следующий экран - грохнули пул и создали все снова, но для нового экрана.

Ну это же какой-то трындец. Если б я такое написал даже в первый год работы - имел бы душеспасительную беседу с техлидом на тему "так делают только пид@%@сы". Здесь нет причины удалять-создавать. Надо создать один раз.

Minx :
Создаем пул, только non-thread-safe. И выдаем каждой нити свой пул.

Если у него и впрямь большое количество пулов - изобрел бы асинхронную реализацию с масштабированием по ядрам, пользы было бы больше. Если небольшое - то см предыдущий пункт.
Кстати, правда, новых языков - как блох на собаке, а вот универсальной асинхронной библиотеки я не встречал, хотя потребность в ней явно есть - в какой крупный проект ни загляни, там либо свои велосипеды на эту тему (nginx), либо треш угар и содомия с потоками (apache). Правда, я давно уже не интересовался.
Надо было делать такую библиотеку самому тогда Улыбка.

Minx :
нужно решать постоянно задачу обхода дерева решений, где при возврате нужно чистить нижеотбрасываемую инфу по дереву

Ну вот тут действительно надо что-то придумывать.
_________________
Конец света в конце тоннеля
    Добавлено: 14:05 20-10-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Diff :
Ну это же какой-то трындец. Если б я такое написал даже в первый год работы - имел бы душеспасительную беседу с техлидом на тему "так делают только пид@%@сы".

Поэтому у Джонатана нет техлида (;

И наверно потому он может делать такие вещи, как Braid.

Diff :
Здесь нет причины удалять-создавать. Надо создать один раз.

Вроде как мы рассмотрели причины выше в топике.

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

Может он и написал. Этож просто пример.

Хотя я не понял при чем тут асинхронная реализация. Делать асинхронный запрос на каждый чих new и delete - это какое-то абы что.

Diff :
универсальной асинхронной библиотеки я не встречал

Универсальных асинхронных велосипедов и библиотек сейчас куча.

Вот в вики список только про Actor model: https://en.wikipedia.org/wiki/Actor_model#Actor_libraries_and_frameworks
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (15:11 20-10-2015), всего редактировалось 2 раз(а)
    Добавлено: 15:09 20-10-2015   
Diff
 708 EGP


Модератор
Рейтинг канала: 2(11)
Репутация: 44
Сообщения: 4179
Откуда: Сферическая Земля в вакууме.
Зарегистрирован: 04.07.2003
Minx :
Хотя я не понял при чем тут асинхронная реализация. Делать асинхронный запрос на каждый чих new и delete - это какое-то абы что.

Я про то, что наштамповать потоков, а потом мужественно бороться с блокировками и синхронизацией - это... ну, собственно, то что почти все и делают. Но вообще-то это делать не обязательно. Другое дело, что в геймдеве это всегда была наименьшая из проблем, ибо геймдев не склонен к многопоточности.
_________________
Конец света в конце тоннеля
    Добавлено: 21:03 20-10-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Diff :
Другое дело, что в геймдеве это всегда была наименьшая из проблем, ибо геймдев не склонен к многопоточности.

За весь геймдев не скажу, и про него вообще мало чего могу сказать, но вот такое я встречаю:

2005 год :
Причем на heap. Этим-то он и хуже.
а еще у него дергается mutex на каждом копировании указателя.
Те, кто бездумно рекомендуют shared_ptr либо не знают как он устроен, либо пишут не игры, а тулзы, где производительность не нужна.

http://www.gamedev.ru/code/forum/?id=34739
Diff :
Я про то, что наштамповать потоков, а потом мужественно бороться с блокировками и синхронизацией - это... ну, собственно, то что почти все и делают.

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

Про слабую многопоточность геймдевовских программ могу только судить по том, как они грузят CPU. Вот у меня сейчас KSP - загружает максимум одно ядро. E: D - где-то на 1.3 ядра. Такую же картину наблюдал в ряде других игрушек. А также архитектурный стиль в виде жесткого cyclic executive.
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (23:25 20-10-2015), всего редактировалось 1 раз
    Добавлено: 23:11 20-10-2015   
Sh.Tac.
 151 EGP


Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426

Зарегистрирован: 27.07.2005
shared_ptr уже давно использует interlockedатомарный increment (всё ещё путаюсь когда дело доходит до виндовых терминов)

касаемо многопоточности я как-то открыл для себя схему MPSC (multiple producers single consumer) и вообще забыл думать о том, как там ещё синхронизировать, потокобезопасный контейнер сам вызывает _lock на каждый push и один раз на consume + спит в остальное время, если потребитель не главный тред там какой-нибудь
_________________
This is what you get ...
(c) Radiohead

Последний раз редактировалось: Sh.Tac. (00:45 21-10-2015), всего редактировалось 1 раз
    Добавлено: 00:41 21-10-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Sh.Tac. :
shared_ptr уже давно использует

Речь идет о
Minx :
Причем на heap. Этим-то он и хуже.
а еще у него дергается mutex на каждом копировании указателя.

т.е. важна фрагментация хипа и дергание mutex'a. А shared_ptr так.. субъект обсуждения (;

Но shared_ptr все равно дергает mutex, на декременте.

добавлено спустя 9 минут:
Sh.Tac. :
я как-то открыл для себя схему MPSC

А мы уже много лет используем SObjectizer, и такого рода проблем нет в принципе, как и множества геммороя в написании практически любой многопоточности, от временных затрат как на разработку, так и на верификацию. И MPSC там один из кирпичиков из коробки.

В общем случае такие схемы как MPSC занимаются общением между потоками, а общение между потоками (если хочется производительности) должно быть сведено к минимуму. Поэтому если хочется скорости, то в любом случае думать надо головой, и серебряной пули далеко нет и даже намека не предвидится.
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (01:31 21-10-2015), всего редактировалось 2 раз(а)
    Добавлено: 01:30 21-10-2015   
Sh.Tac.
 151 EGP


Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426

Зарегистрирован: 27.07.2005
Minx :
shared_ptr все равно дергает mutex, на декременте
нет же, если смогли осилить инкремент, то и декремент туда же Улыбка

Цитата:
И MPSC там один из кирпичиков из коробки
ага, помницца даже выкинул свой контейнер когда убедился, что boost::asio::io_service делает ровно то же самое, но знание это опять пригодилось для UE4, в общем иногда полезно что-то делать на уровне "кирпичика"

добавлено спустя 10 минут:
З.Ы. по поводу interlocked меня смутил гугл, который в качестве релевантного подсовывает например такой пост, чувак явно пишет про lock и ещё получает плюсы Совсем запутался...

добавлено спустя 2 минуты:
З.З.Ы. атомики в ходу с 2008 точно, если что
_________________
This is what you get ...
(c) Radiohead

Последний раз редактировалось: Sh.Tac. (01:55 21-10-2015), всего редактировалось 2 раз(а)
    Добавлено: 01:55 21-10-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Sh.Tac. :
нет же, если смогли осилить инкремент, то и декремент туда же

Блин.. почему-то на основании этого поста Саттера думал, что декремент менее производителен. А сейчас уже таких следов нету..
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 02:35 21-10-2015   
Sh.Tac.
 151 EGP


Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426

Зарегистрирован: 27.07.2005
кста кто что думает про ThreadPool в контексте быстродействия синхронизации?

я везде выкидывал когда видел, задачно-ориентированный подход имхо лучче и опять же укладывается в MPSC Улыбка
_________________
This is what you get ...
(c) Radiohead
    Добавлено: 03:52 21-10-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Смысл любого пула в основном в том, что не нужно заново создавать окружение для решения задачи. Т.е. если для решения задачи нужно иметь коннект к БД, привязанный к нити, то пул избавляет от такой проблемы.

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

Также пул может иметь настраиваемые параметры, например число одновременно работающих нитей (min/max), кол-во запросов в очереди (ожидающих если max) и т.д. Потому что для high-load часто получается так, что ограничение max спасает от деградации системы и позволяет в случае ахтунга её держать на пике производительности. И техподдержка может быть более довольна - получает например бегунки min/max и дополнительную свободу для танцев с бубном.
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 12:54 21-10-2015   
Sh.Tac.
 151 EGP


Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426

Зарегистрирован: 27.07.2005
Minx :
коннект к БД, привязанный к нити, то пул избавляет от такой проблемы.
опасная штука, нужно всё заворачивать в транзакции тогда, а то можно прочитать что-нибудь не того пока другой тред пишет
_________________
This is what you get ...
(c) Radiohead
    Добавлено: 17:28 21-10-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Sh.Tac. :
опасная штука, нужно всё заворачивать в транзакции тогда, а то можно прочитать что-нибудь не того пока другой тред пишет

Транзакционность и обеспечение целостности/инвариантов в БД это основы. Без них в БД вообще лучше не лезть.

Нити и пулы необязательно могут быть 1 к 1 в БД. Например, ломится много одиночных запросов по какому-нибудь HTTP, и на уровне БД нужно обеспечить одиночную вставку присланных данных, и только потом отвечать HTTP OK. Вставлять по одному не выгодно (долго), целой нитью ждать на один HTTP жирно (там данные плетутся долго), поэтому ресурсы нитей деляться между запросами, а вставку нужно делать массовым INSERT'ом. Делается пул например в 100 потоков и 8 нитей (например по 2 на железное ядро, но это не строгое правило), и вешается барьер на 20 мьютексов. Приползло 20 полноценных HTTP - массовый INSERT в 20 шт. Не приползло - INSERT послабее по таймауту. Приползло очень много, БД не успевает даже массовыми вставками - все в очередь на ожидание свободных мест пула.

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

Ещё бывают случаи когда удобно абстрактно разбивать ресурсы по сущностям типа пулов. Например, запрос обрабатывается в три этапа A, B и С. Каждому из них дали по пулу каким-то размером и в какое-то число нитей. Запускаем нагрузку. Если получается, что один из (например B) начинает просаживаться, то перебрасываем ресурсов из одного этапа в другой (из A или C в B).
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (18:24 21-10-2015), всего редактировалось 1 раз
    Добавлено: 18:13 21-10-2015   
Sh.Tac.
 151 EGP


Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426

Зарегистрирован: 27.07.2005
Minx :
Транзакционность и обеспечение целостности/инвариантов в БД это основы.
в геймдеве эти основы в основном попираются Улыбка
т.к. БД обычно нужно просто как долговременное хранилище, желательно быстрое и масштабируемое, вот и развелось всяких NoSQL + одни и те же данные на разных узлах могут быть неконсистентны, и с этим приходится работать
_________________
This is what you get ...
(c) Radiohead
    Добавлено: 19:30 21-10-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Sh.Tac. :
в геймдеве эти основы в основном попираются

Полагаю что это потому, что одно дело если геймеру не записалось в БД первооткрытие одной звезды из 1000 в E: D, и совершенно другое, если человек положил на счет в банке, и сумма не положилась с вероятностью 0.1%. Или ещё более совсем другое, если вероятность не перейти улицу 0.1%.

Хотя с целостностями вроде даже у Амазона проблемы [были?].
_________________
μηδείς αγεωμέτρητος εισίτω
    Добавлено: 19:43 21-10-2015   
Shirson
 1605 EGP


Модератор
Рейтинг канала: 7(626)
Репутация: 219
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
Minx :
совершенно другое, если человек положил на счет в банке, и сумма не положилась с вероятностью 0.1%.

Если занудствовать, то это крайне неудачный пример Улыбка - транзакционность, именно тут, никак проблему не решает.
Она решает, когда делаются транзакции со счёта на счёт, в чистом виде. Тогда либо есть перевод, либо нету (и можно повторить) - целостность операции.
А вот если засунул бапки в автомат, а что-то сбойнуло и транзакция в БД не прошла, тут без разницы - откат транзакции кэш из банкомата не выплюнет Подмигиваю
_________________
У меня бисера не доxеpа.
    Добавлено: 19:57 21-10-2015   
Minx
 978 EGP


Модератор
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
Shirson :
Если занудствовать, то это крайне неудачный пример - транзакционность, именно тут, никак проблему не решает.
Речь идет о dirty read:
Sh.Tac. :
можно прочитать что-нибудь не того пока другой тред пишет

т.е. например есть две операции из разных точек X и Y: одновременно два человека ложат на один и тот же счет по 1000$.

Алгоритм:
1. Считать состояние счета.
2. Прибавить 1000$.
3. Записать результат в счет.

Без транзакции:
1. X считывает текущее состояние счета (A).
2. Y считывает текущее состояние счета (A).
3. X прибавляет 1000$ (A+1000$). Записывает на счет A+1000$.
4. Y прибавляет 1000$ (A+1000$). Записывает на счет A+1000$.

Результат - на счете A+1000$ вместо ожидаемого A+2000$.
Нарушение целостности/инварианта - дебет с кредитом у сторон не сходится.

С транзакцией:
1. Старт транзакции X. X считывает текущее состояние счета (A).
2. Попытка старта транзакции Y. Ожидание.
3. X прибавляет 1000$ (A+1000$). Записывает на счет A+1000$. COMMIT.
4. Просыпается Y. Y считывает текущее состояние счета (A + 1000$).
5. Y прибавляет 1000$ (A+2000$). Записывает на счет A+2000$. COMMIT.
6. PROFIT.

Вообще, я даже в двух местах типа учебников этот пример с банкоматами как необходимость синхронизации/транзакционности видел.
_________________
μηδείς αγεωμέτρητος εισίτω

Последний раз редактировалось: Minx (20:09 21-10-2015), всего редактировалось 3 раз(а)
    Добавлено: 20:05 21-10-2015   
Sh.Tac.
 151 EGP


Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426

Зарегистрирован: 27.07.2005
по поводу консистентности мне в своё время понравилась картинка с CAP theorem, оказывается в ряде случаев это вообще не важно
 Cкрытый текст   (кликните здесь для просмотра)

_________________
This is what you get ...
(c) Radiohead
    Добавлено: 20:28 21-10-2015   
Канал Игры Мечты: «Два пути - количество или качество игр»
На страницу: Пред.  1, 2, 3, 4, 5  След. | Все страницы
  
Показать: 
Предыдущая тема | Следующая тема |
К списку каналов | Наверх страницы
Цитата не в тему: Трудовые флудерские мозоли не путай с мозолями от удовольствия! (Lisnick о труде флудеров)

  » Два пути - количество или качество игр | страница 4
Каналы: Новости | Elite | Elite: Dangerous | Freelancer | Star Citizen | X-Tension/X-BTF | X2: The Threat | X3: Reunion | X3: Terran Conflict | X Rebirth | X4: Foundations | EVE Online | Orbiter | Kerbal Space Program | Evochron | VoidExpanse | Космические Миры | Онлайновые игры | Другие игры | Цифровая дистрибуция | play.elite-games.ru | ЗВ 2: Гражданская война | Творчество | Железо | Игра Мечты | Сайт
   Дизайн Elite Games V5 beta.18