Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
А зачем тебе время? Тупо снимай иммутабельный слепок состояния, его передавай потокам, каждый worker ограничен не по времени, в по числу итераций. Когда все вокреры отработали — уже делай отрисовку. Соответственно тебе будет вообще пофиг, это однопроцессорная одноядерная машина или какой 100 ядерный монстр.
ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
Создать очередь ConcurrentQueue<Computation>
Computation это расчёт. Допустим все Computation выполняются за одно и то же время и все игроки создают их с одинаковой скоростью.
Запустить n потоков (оптимально n — число ядер CPU).
В каждом потоке доставать в цикле из очереди Computation и выполнять его.
Если Computation по времени исполнения разные, то мудрить с тем кому можно сейчас добавить в очередь свой Computation.
Если ранее добавил тяжелый Computation и хочешь ещё, подожди дай другие добавят вперёд тебя.
Если скорость создания игроками Computation разная, тоже мудрить аналогично
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
А что, есть такая проблема? Ты уже точно уверен, что куму-то недодают времени?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
а точнее? ты можеш гарантировать что все нити стартанут одновременно, но если ты код потоков не контролируеш и код чужой то ты им время раз ве как то ограничиш? в линуксе есть cgroups и dotnet core умеет корректно их учитывать для системных метрик, но напрямую из managed кода ими управлять нельзя. и cgroups для процессов а не потоков.
VC> код потоков не контролируешь и код чужой то ты им время раз ве как то ограничишь?
Я могу наложить на код требования, такие как "не запускать новых потоков, новых процессов".
Выполнение требований проверять просмотром исходного кода на наличие ключевых слов.
Ну или уже сборку проверять на наличие вызовов (хотя это пока не представляю как сделать).
VC>> можешь гарантировать что все нити стартанут одновременно
Плюс-минус несколько секунд это некритично, поэтому да, могу.
M> А что, есть такая проблема? Ты уже точно уверен, что куму-то недодают времени?
Я хочу иметь обоснование, что всем всё додают.
Например, если код асинхронный, и нити все из пула, то у меня нет уверенности, что разные AI получают одинаковое количество времени.
E> каждый worker ограничен не по времени, в по числу итераций.
Я ничего не понял. Что такое итерация? Ты мне предлагаешь делать виртуальный процессор и считать виртуальные инструкции вручную?
Просто представь, что алгоритмы AI разные, и работу за один условный ход они проделывают разную.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
Пусть появился игрок, который исчерпал лимит. Что с ним будешь делать?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я ничего не понял. Что такое итерация? Ты мне предлагаешь делать виртуальный процессор и считать виртуальные инструкции вручную? ЭФ>Просто представь, что алгоритмы AI разные, и работу за один условный ход они проделывают разную.
Если ты сказал про время, то у тебя алгоритмы скорее всего итеративные, в каждой итерации алгоритм выдает лучшее и лучшее решение. Иначе ты бы тупо считал до остановки. Потому имеет смысл ограничить количество итераций каким конфигом или нужной точностью. Параметры конфига ты можешь подобрать эмпирически, также можешь на конкретном процессоре при старте запустить какой бенчмарк чтобы посмотреть насколько эти параметры нужно подкорректировать на конкретном железе. Бенчмарк однопоточный и тупой как пробка делать.
Просто ограничивать по времени тебе скорее всего не надо. Ибо если у тебя реально появилась необходимость уложиться в определенное время, то тебе нужно использовать не винду ликунс макось, а специальные системы реального времени, которые из коробки дают гарантию отклика за внешнее воздействие за определенное количество времени, но при этом жертвуя общей эффективностью. Винда линукс макось таких гарантий не предоставляют даже в рамках процессов, про потоки даже говорить нет смысла, соответственно ничего путного ты не сделаешь.
Б> Пусть появился игрок, который исчерпал лимит. Что с ним будешь делать?
Игра условно пошаговая. Если время на ход закончилось, то для реализации принимаются текущие наработанные идеи игрока, у него отбирается процессор и отдаётся тем, кто ещё не насчитал до лимита.
E> Параметры конфига ты можешь подобрать эмпирически
Ты предполагаешь, что все AI одинаковые. Представь себе игру типа шахмат. Там конечно можно просчитать всё, только времени на это не хватит ни как.
Поэтому приходится вводить ограничение, которое связано с человеческими физиологическими характеристиками (сколько не надоедает ждать).
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Ты предполагаешь, что все AI одинаковые. Представь себе игру типа шахмат. Там конечно можно просчитать всё, только времени на это не хватит ни как. ЭФ>Поэтому приходится вводить ограничение, которое связано с человеческими физиологическими характеристиками (сколько не надоедает ждать).
Я сам работаю в отрасли где нужно выдать результат за определенное время, части алгоритма могут выполняться параллельно, и зачастую впараллель запускаются несколько конкурирующих алгоритмов и через определенное время управление говорит стоп и выбирается наилучшее решение из того, что посчиталось. Так вот, нет необходимости давать разным алгоритмам одинаковое процессорное время. Они вообще то могут работать на разных нодах кластера вообще то, ноды могут быть загружены другими задачами. Единственный смысл, который может быть — это прибивать все к чертям если не уложился в лимит времени, говоря давай те результаты что есть, больше ждать нельзя.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Это нужно в том случае, если алгоритмы играют друг против друга. ЭФ>Иначе как понять, какой из алгоритмов играет лучше?
Если тебе реально нужно это понять — гоняй разные алгоритмы на разных свободных нодах, на одной и той же ОС на одном и том же железе, максимально убедившись что еще кто там что не запускает, соответственно соревнуйтесь. Иначе будет погрешность. Можно не заморачиваться, тупо запустить по потоку на алгоритм, но если ОС приспичило поток вытеснить — значит не повезло потоку, повезет в другой раз. Предполагаю что совсем жутко ОС будет вмешаваться достаточно редко и сможешь получить достаточные для примерного понимания результаты.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
Что-то подсказывает мне, что эта задача не решаемая, кроме RTC OS.
Но если ты в разных потоках считаешь каждого игрока-AI и заодно людей, то пока человек тУпит в монитор на картинку, cpu может сделать сильно многое. И кроме того, что мешает алгоритму считать постоянно. Ведь человек играя постоянно прокручивает игру в голове, почему AI надо перезапускать каждый раз.
А если цель померять потраченное время, то можно поступить как разработчики MS SQL, ввести метрики и считать время, потраченное на то, на сё, на это, на вот это. Что именно — зависит от реализации алгоритмов и их разделения на функциональные блоки. Алгоритм AI по мере работы увеличивает метрики, их можно узнать, журналировать, анализировать у кого что где когда ушло, вплоть до стадии игры. Так что предлагаю не ограничивать время работы, а считать его.
Допустим, ходы происходят раз в 4 минуты, всё это время думают и люди и их противники.
Время на ход ограничено этими 4-мя минутами, но я не предполагаю давать AI меньшее количество времени.
Под "ограничивать", я имел в виду как обеспечить такую политику, чтобы один
AI не переиспользовал процессорное время, своровав его у всех других AI (и победив за счёт этого).
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Допустим, ходы происходят раз в 4 минуты, всё это время думают и люди и их противники.
Если я правильно читал, игра у тебя пошаговая. Это минимум 2 условных этапа, этап формирования приказов шага (возможно, совмещённый с информированием людей о произошедшем на предыдущем шаге) и этап исполнения собранных приказов и просчёта шага. На этапе формирования и AI, и люди формируют очередь воздействий на мир в соответствиями с правилами (с валидацией допустимости воздействий).
Кто как заполнил очередь приказов, тот так себе и Буратино.
Весь вопрос, хватит ли людям 4 мин макс на адекватную реакцию на изменения в мире, или их тонус переполнится и они с воплями про коня забьют на игру. AI-то по любому успеет.
ЭФ>Время на ход ограничено этими 4-мя минутами, но я не предполагаю давать AI меньшее количество времени. ЭФ>Под "ограничивать", я имел в виду как обеспечить такую политику, чтобы один ЭФ>AI не переиспользовал процессорное время, своровав его у всех других AI (и победив за счёт этого).
Вот тут я предлагаю не искать хитрого и вороватого, а вести учёт времени по каждому игроку, сколько времени он потратил и на что, не важно, человек или AI.
Человек думает, потом формирует приказ. Значит время между приказами у него уходит на обдумывание приказа, первый приказ — с момента показа состояния текущего шага. Можно замерять, сколько времени он что смотрел.
Для AI тоже можно выделить функциональные части, и замерять время на них потраченное. Сколько ушло на выявление главной цели, сколько на второстепенные и определение их количества. Приказывает AI явно быстрее человека, мышью водить не нужно.
Писать в журнал эти метрики на каждом шаге и всего за игру, и будет видно, как справляются игроки, где и когда у них затык и цугцванг.
Имея на руках тайминги и сами приказы можно судить об эффективности алгоритмов.
Наконец, можно схитрить и на этапе исполнения ещё немного времени дать AI "подумать".
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Железо будет недоиспользоваться. Задавили один из AI и всё — его физическое железо простаивает...
Зато будет достаточно честный бенчмарк. Я собственно не очень понимаю зачем гарантированно ставить различные AI в равные условия кроме именно соревновательных. Если мы возьмем именно игры, то если мы заморачиваться не будем, то в среднем каждый поток один черт будет примерно в равных условиях, естественно при условиях что число потоков меньше чем количество ядер процессора. Да и даже если какой AI получит преимущество не честно, ну и хрен с ним. Тебе нужно то сделать чтоб игроку было интересно. Или у тебя игра программисткая, соответственно игрок кодит эти AI и далее они сравниваются кто лучше накодил?
A> вопрос, хватит ли людям 4 мин макс на адекватную реакцию на изменения в мире
Вот это вообще не вопрос. Можно ведь сделать завершение хода по мере готовности человека.
Если ему понадобится пять минут, ну значит AI тогда получат эту дополнительную минуту, так как думают в то же время.
Здравствуйте, Эйнсток Файр, Вы писали:
E>> каждый worker ограничен не по времени, в по числу итераций. ЭФ>Я ничего не понял. Что такое итерация? Ты мне предлагаешь делать виртуальный процессор и считать виртуальные инструкции вручную? ЭФ>Просто представь, что алгоритмы AI разные, и работу за один условный ход они проделывают разную.
Нужно опираться не на реальное время, а на внутриигровые такты. Такт — это атомарное действие в рамках игры. Скажем, игрок 1 делает шаг на север — это отнимает один такт. Далее всем игрокам выдаётся одинаковое количество тактов.
ВВ>Нужно опираться не на реальное время, а на внутриигровые такты. Такт — это атомарное действие в рамках игры. Скажем, игрок 1 делает шаг на север — это отнимает один такт. Далее всем игрокам выдаётся одинаковое количество тактов.
Проблема моей игры в том, что там надо мало двигаться и много думать. И кто больше думает — быстрее выигрывает.
Что толку, если они будут двигаться одинаково, но при этом один из них будет это делать на пару порядков умнее?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Проблема моей игры в том, что там надо мало двигаться и много думать. И кто больше думает — быстрее выигрывает.
Поэтому я предложил тебе сначала измерить, кто сколько времени "думает" и на какие думы он это время тратит, что позволит разбить одну думу на стадии и выявить наличие узких мест.
Возможно, что все укладываются в 4 мин, и ещё 2/3 времени бездействуют.
Здравствуйте, Эйнсток Файр, Вы писали:
ВВ>>Нужно опираться не на реальное время, а на внутриигровые такты. Такт — это атомарное действие в рамках игры. Скажем, игрок 1 делает шаг на север — это отнимает один такт. Далее всем игрокам выдаётся одинаковое количество тактов.
ЭФ>Проблема моей игры в том, что там надо мало двигаться и много думать. И кто больше думает — быстрее выигрывает. ЭФ>Что толку, если они будут двигаться одинаково, но при этом один из них будет это делать на пару порядков умнее?
То есть надо, чтобы процессорных ресурсов каждому такому "игроку" выделялось абсолютно одинаковое количество? Мне кажется, тут такое "в лоб" решить не получится. Зависит от того, как AI "думает". Если это можно представить в виде оп-кодов для виртуальной машины, то тогда и исполнять последовательно — оп-код одного "игрока", затем "другого". Да и то возникает вопрос в равноценности разных оп-кодов. Это уже надо смотреть более предметно.
ВВ> исполнять последовательно — оп-код одного "игрока", затем "другого"
Чисто теоретически это необязательно (переключаться через каждый опкод).
Можно выполнять по N опкодов подряд и затем переключаться.
Будет погрешность, но она будет контролируемая.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как в дотнете организовать многопоточное приложение таким образом, чтобы нити, выполняющие расчёты за разных AI-игроков, получали одинаковое количество процессорных ресурсов в час (или в другой промежуток времени)?
Для винды можно использовать WinAPI: GetThreadTimes, SuspendThread, ResumeThread.
То есть запустить каждого AI-игрока в отдельном потоке, а ещё одним управляющим потоком периодически замерять время, потраченное потоками игроков, и те потоки, которые потратили времени больше других, ставить на паузу соответствующей продолжительности.
Здравствуйте, Эйнсток Файр, Вы писали:
ВВ>> исполнять последовательно — оп-код одного "игрока", затем "другого" ЭФ>Чисто теоретически это необязательно (переключаться через каждый опкод). ЭФ>Можно выполнять по N опкодов подряд и затем переключаться. ЭФ>Будет погрешность, но она будет контролируемая.
А вам исполнение нескольких оп-кодов подряд никаких преимуществ не даст, только усложнение реализации. Впрочем, это уже детали, смотрите сами.
AI-то по любому успеет.
