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

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?

а точнее? ты можеш гарантировать что все нити стартанут одновременно, но если ты код потоков не контролируеш и код чужой то ты им время раз ве как то ограничиш? в линуксе есть cgroups и dotnet core умеет корректно их учитывать для системных метрик, но напрямую из managed кода ими управлять нельзя. и cgroups для процессов а не потоков.

VC> код потоков не контролируешь и код чужой то ты им время раз ве как то ограничишь?

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

Ну или уже сборку проверять на наличие вызовов (хотя это пока не представляю как сделать).

VC>> можешь гарантировать что все нити стартанут одновременно

Плюс-минус несколько секунд это некритично, поэтому да, могу.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?

А что, есть такая проблема? Ты уже точно уверен, что куму-то недодают времени?

M> А что, есть такая проблема? Ты уже точно уверен, что куму-то недодают времени?

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

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?

Если на винде, то можно попробовать файберы
https://blog.adamfurmanek.pl/videos-talks-papers-articles/async-with-coroutines-and-fibers-in-c/

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
А зачем тебе время? Тупо снимай иммутабельный слепок состояния, его передавай потокам, каждый worker ограничен не по времени, в по числу итераций. Когда все вокреры отработали — уже делай отрисовку. Соответственно тебе будет вообще пофиг, это однопроцессорная одноядерная машина или какой 100 ядерный монстр.

E> каждый worker ограничен не по времени, в по числу итераций.

Я ничего не понял. Что такое итерация? Ты мне предлагаешь делать виртуальный процессор и считать виртуальные инструкции вручную?
Просто представь, что алгоритмы AI разные, и работу за один условный ход они проделывают разную.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?

Пусть появился игрок, который исчерпал лимит. Что с ним будешь делать?

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Я ничего не понял. Что такое итерация? Ты мне предлагаешь делать виртуальный процессор и считать виртуальные инструкции вручную?
ЭФ>Просто представь, что алгоритмы AI разные, и работу за один условный ход они проделывают разную.
Если ты сказал про время, то у тебя алгоритмы скорее всего итеративные, в каждой итерации алгоритм выдает лучшее и лучшее решение. Иначе ты бы тупо считал до остановки. Потому имеет смысл ограничить количество итераций каким конфигом или нужной точностью. Параметры конфига ты можешь подобрать эмпирически, также можешь на конкретном процессоре при старте запустить какой бенчмарк чтобы посмотреть насколько эти параметры нужно подкорректировать на конкретном железе. Бенчмарк однопоточный и тупой как пробка делать.

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

Б> Пусть появился игрок, который исчерпал лимит. Что с ним будешь делать?

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

E> Параметры конфига ты можешь подобрать эмпирически

Ты предполагаешь, что все AI одинаковые. Представь себе игру типа шахмат. Там конечно можно просчитать всё, только времени на это не хватит ни как.
Поэтому приходится вводить ограничение, которое связано с человеческими физиологическими характеристиками (сколько не надоедает ждать).

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ты предполагаешь, что все AI одинаковые. Представь себе игру типа шахмат. Там конечно можно просчитать всё, только времени на это не хватит ни как.
ЭФ>Поэтому приходится вводить ограничение, которое связано с человеческими физиологическими характеристиками (сколько не надоедает ждать).
Я сам работаю в отрасли где нужно выдать результат за определенное время, части алгоритма могут выполняться параллельно, и зачастую впараллель запускаются несколько конкурирующих алгоритмов и через определенное время управление говорит стоп и выбирается наилучшее решение из того, что посчиталось. Так вот, нет необходимости давать разным алгоритмам одинаковое процессорное время. Они вообще то могут работать на разных нодах кластера вообще то, ноды могут быть загружены другими задачами. Единственный смысл, который может быть — это прибивать все к чертям если не уложился в лимит времени, говоря давай те результаты что есть, больше ждать нельзя.

E> нет необходимости давать разным алгоритмам одинаковое процессорное время.

Это нужно в том случае, если алгоритмы играют друг против друга.
Иначе как понять, какой из алгоритмов играет лучше?

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Это нужно в том случае, если алгоритмы играют друг против друга.
ЭФ>Иначе как понять, какой из алгоритмов играет лучше?
Если тебе реально нужно это понять — гоняй разные алгоритмы на разных свободных нодах, на одной и той же ОС на одном и том же железе, максимально убедившись что еще кто там что не запускает, соответственно соревнуйтесь. Иначе будет погрешность. Можно не заморачиваться, тупо запустить по потоку на алгоритм, но если ОС приспичило поток вытеснить — значит не повезло потоку, повезет в другой раз. Предполагаю что совсем жутко ОС будет вмешаваться достаточно редко и сможешь получить достаточные для примерного понимания результаты.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
Что-то подсказывает мне, что эта задача не решаемая, кроме RTC OS.
Но если ты в разных потоках считаешь каждого игрока-AI и заодно людей, то пока человек тУпит в монитор на картинку, cpu может сделать сильно многое. И кроме того, что мешает алгоритму считать постоянно. Ведь человек играя постоянно прокручивает игру в голове, почему AI надо перезапускать каждый раз.
А если цель померять потраченное время, то можно поступить как разработчики MS SQL, ввести метрики и считать время, потраченное на то, на сё, на это, на вот это. Что именно — зависит от реализации алгоритмов и их разделения на функциональные блоки. Алгоритм AI по мере работы увеличивает метрики, их можно узнать, журналировать, анализировать у кого что где когда ушло, вплоть до стадии игры. Так что предлагаю не ограничивать время работы, а считать его.

A> предлагаю не ограничивать время работы

Допустим, ходы происходят раз в 4 минуты, всё это время думают и люди и их противники.
Время на ход ограничено этими 4-мя минутами, но я не предполагаю давать AI меньшее количество времени.
Под "ограничивать", я имел в виду как обеспечить такую политику, чтобы один
AI не переиспользовал процессорное время, своровав его у всех других AI (и победив за счёт этого).

E> гоняй разные алгоритмы на разных свободных нодах, на одной и той же ОС на одном и том же железе

Железо будет недоиспользоваться. Задавили один из AI и всё — его физическое железо простаивает...

ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?

Создать очередь ConcurrentQueue<Computation>
Computation это расчёт. Допустим все Computation выполняются за одно и то же время и все игроки создают их с одинаковой скоростью.
Запустить n потоков (оптимально n — число ядер CPU).
В каждом потоке доставать в цикле из очереди Computation и выполнять его.
Если Computation по времени исполнения разные, то мудрить с тем кому можно сейчас добавить в очередь свой Computation.
Если ранее добавил тяжелый Computation и хочешь ещё, подожди дай другие добавят вперёд тебя.
Если скорость создания игроками Computation разная, тоже мудрить аналогично

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Допустим, ходы происходят раз в 4 минуты, всё это время думают и люди и их противники.
Если я правильно читал, игра у тебя пошаговая. Это минимум 2 условных этапа, этап формирования приказов шага (возможно, совмещённый с информированием людей о произошедшем на предыдущем шаге) и этап исполнения собранных приказов и просчёта шага. На этапе формирования и AI, и люди формируют очередь воздействий на мир в соответствиями с правилами (с валидацией допустимости воздействий).
Кто как заполнил очередь приказов, тот так себе и Буратино.

Весь вопрос, хватит ли людям 4 мин макс на адекватную реакцию на изменения в мире, или их тонус переполнится и они с воплями про коня забьют на игру. AI-то по любому успеет.

ЭФ>Время на ход ограничено этими 4-мя минутами, но я не предполагаю давать AI меньшее количество времени.
ЭФ>Под "ограничивать", я имел в виду как обеспечить такую политику, чтобы один
ЭФ>AI не переиспользовал процессорное время, своровав его у всех других AI (и победив за счёт этого).
Вот тут я предлагаю не искать хитрого и вороватого, а вести учёт времени по каждому игроку, сколько времени он потратил и на что, не важно, человек или AI.

Человек думает, потом формирует приказ. Значит время между приказами у него уходит на обдумывание приказа, первый приказ — с момента показа состояния текущего шага. Можно замерять, сколько времени он что смотрел.
Для AI тоже можно выделить функциональные части, и замерять время на них потраченное. Сколько ушло на выявление главной цели, сколько на второстепенные и определение их количества. Приказывает AI явно быстрее человека, мышью водить не нужно.
Писать в журнал эти метрики на каждом шаге и всего за игру, и будет видно, как справляются игроки, где и когда у них затык и цугцванг.
Имея на руках тайминги и сами приказы можно судить об эффективности алгоритмов.
Наконец, можно схитрить и на этапе исполнения ещё немного времени дать AI "подумать".