Алексей, а рассматривалась ли такая альтернативная идея контроля над зависанием и прочим «несанкционированным потреблением CPU» — нода с игрой и решением запускаются в одном процессе, но по команде специального второго примитивного процесса-раннера, который через 120+1 секунду кидает контролируемому процессу килл-сигнал и всё. Есть --log=log.json, хорошо, решение отработало нормально. Нет значит переело процессора любым способом. Естественно, требование «ничего нельзя require, в том числе пользоваться файловой системой (и как-либо взламывать движок игры)» остаётся в силе.
Да я уже потом вне конкурса ради спортивного интереса запилил суровый холодный старт, мол сиди 600 фреймов думай как будешь карту рулить, а потом всё почти как и в оригинальном решении: от оставшихся фреймов (600) он 1/3 времени (200) гоняется за бабочками пока они есть, и в оставшиеся 2/3 (400 фреймов) лопает алмазы. А почти — потому как при беге весь «дорасчёт» выкинут в комментарий и оставлена только отдача очередной буквы из (ранее найденного) лучшего пути развития событий.
Можно конечно меньше разогреваться, 400 или 300 (на моём железе хватало вполне), но зачем, если практически каждый уровень разбирается примерно за 400 ходов.
Получаю 8451 очков на финальном сете (правда на моём проце) и 6-е место. Но это ж он минуту целую стоит и курит. Сколько раз его за это время могли лопатой по голове стукнуть в случае двух игроков. =)
Если брать в рамках одного ДЦ и понимать что больше 600 запросов в минуту от одного клиента точно не будет и одновременно сражаются, скажем, не более 8 участников, то о факторе сети можно практически забыть.
Интересно, Алексей feldgendler, а в каком режиме работают те целевые конкурсные процессоры на Амазоне? Хотя мы наверное не хотели устраивать челендж на особенности такого-то процессора, но так получилось… )
А вообще, как насчёт формата следующего игрового конкурса с двумя машинами и взаимодействию по JSON API?
На одной сервер, реализующий это API, с игрой, которая (возможно, после обмена синхронизационными запросами) по команде старта от клиента или же самостоятельно, отвечая клиентам статусом со временем предстоящего запуска, начинает свой неумолимый ход жизни мира с метрономскими тиками.
На другой машине — игровой клиент, который будет это API использовать. Пытаться управлять своим игроком в этом мире, пытаясь набрать счёт.
Синхронизация решается достаточно просто, были б таймстампы в соотв. методах API.
Независимость работы машин очевидна.
В случае параллельной игры нескольких игроков в равные условия все могут быть легко поставлены, когда клиентские машины с решениями, например, размещаются в одном и том же ДЦ. Можно заодно устранить значимую часть лагов, поместив их в тот же ДЦ, что сервер, а можно в другой и сделать из (умеренных) лагов фишку.
На мой взгляд может получиться очень, очень интересный челендж, лишённый многих проблем одномашинного запуска и очень приближенный к боевым условиям.
К слову, из-за проблемы непредсказуемого пропуска хода в боевом (с воркерами) режиме, залипание это вынужденная мера. Серьёзно, я даже когда оставил боту на текущий расчёт 30 мс из 100, всё равно в один из сотни запусков нештатный пропуск хода случался. Поэтому и я позже пришёл к идее «олимпиадности» решения и неизбежности прогрева, но уже не успел её запилить до дедлайна.
Да и хотел изначально сделать более приближенного к реальности бота — конкретные условия конкретными условиями, но всё же, блин, карта может в реале быть иного размера, игрок может находиться в нескольких клетках под падающей бомбой или в нескольких клетках на пути ножниц… то есть бабочек, и ему нужно бежать, бежать, сразу бежать. Или может если он будет стоять то упустит возможность сожрать какие-то близкие алмазы, пока всё изначально падает-бежит в уровне и всё такое.
Так что сейчас в предварительных результатах моё 7-е чудо тоже бежит сразу с места стартуя и размышляя на ходу. И доступное процессорное время в тике для него решающе важно. Ридми не делал, зато с именами переменных порядок, комментарии семантические присутствуют и всё такое.
etc
Правда там кучу лишнего временного/старого закомментированного кода и пару старых функций не выкинул, дебаг недочищен, — думал успею что-то ещё путное дописать и красоту навести, но чутка не хватило времени, как ж без этого.
Под любой, полагаю. Тестировалось под виндой семёркой и у товарища под макосью. Нестабильность проявляется одинаково примерно. И это при полном контроле за фактическими временами выполнения обдумывания ходов, все без исключений укладывались с огромным запасом (20мс+) в 100мс.
А каким образом это может быть связано с энергосбережением (опять же при учёте что мы фактические тайминги измеряем)? Процы на экспериментальных системах имели по более чем 2 физических ядер и не были заняты ничем иным.
Да, правильно. Да скорее это уже бурчание на то, что за дела в этом воркер режиме происходят, — сори за многобукв и в дцатый раз спасибо за классный конкурс.
Возможно это потому, что они на слабом железе не успевают сделать даже какого-то критического минимума за отведённые 100мс +- random(0, 1) * 60мс. Базовый расчёт до конца доходит, но случайные пропуски хода, фьють. Попробуйте ради интереса с -p флагом, может внезапно окажется, что большинство решений вполне годные. :-)
Честно говоря, эти странные непредсазуемые пропуски хода в воркер режиме полсилы решения отправили в ведро. =/
Уже при 50мс начинались значимые случайные… сбои синхронизации? Что-то начиналось. Даже при 40мс иногда. И бот ловил внеплановый пропуск хода, после чего остальные продуманные им ходы летели в печь. И из-за нестыковки того, какой он думает сейчас фрейм и какой в действительности фрейм, происходило вот это вот долбление о стены, умирание под камнями и прочее подобное.
PS: Ну и если, вдруг, тестирование будет решено производить в формате -p с контролем уже общего времени работы процесса игры = 120 +- 1 секунд (чтоб решения ну не могли «тупить» в зачёте) — то было бы вполне справедливо поправить решениям настройку «сколько можно думать» со слишком урезанных таймингов до 80мс. Наверняка такая настройка есть у многих вариантов. Или, не знаю, дать всем какой-нибудь «вторник допиливания», о котором объявить завтра. … Ну или оставить как есть, честно не знаю.
А, да, и ещё интересный вопрос ко всем. Кто сколько времени от фрейма 100мс позволял считать ходы своим решениям?
Просто в однопроцессном (-p) режиме не было никаких проблем, когда разрешал считать своему 80 мс из 100, зная, что возможное лишнее время от разрешённых 80 мс не уйдёт более +5..10 мс. Но в «боевом режиме» такой формат обсчёта приводил к непредсказуемым пропускам хода (при этом никаких явных вылетов за разрешённые рамки не было), и для стабильности пришлось урезать доступное время расчёта до, блин, 30 мс из 100.
Не знаю, может что делал не так, но очень неприятный момент, и не совсем понятно, что же именно мешает при запуске в воркер режиме.
А суть кода главного цикла примерно такая:
function getNow() {
return Date.now() * 1000;
//var ht = process.hrtime();
//return (ht[0] * 1000000 + ht[1] / 1000)|0;
}
// ...
exports.play = function*(screen)
{
// ...
var ai = new DashAI(screen);
var timeStart = getNow();
var timeTill = timeStart + (ai.frameCalcTimeout * 0.5)|0;
ai.think(timeTill);
while (ai.frame < ai.framesMax) {
var move = ai.getNextMove();
ai.think(timeTill);
yield move;
timeStart = getNow();
timeTill = timeStart + ai.frameCalcTimeout;
}
}
где ai.frameCalcTimeout пришлось ставить 30 мс.
Признателен, если кто-то пояснит, в чём тут может быть проблема, и как «вернуть» в пользование время порядка 80-90мс из 100.
Да уж, 2,8 ГГц вместо не тех 2,5 ГГц должны дать заметную разницу. И кстати отжельный интерес представляет и то как решения справлялись с задачей на том и другом типе процессоров, раз уж уже протестировано.
Тоже верно, но и до антропоморфных роботов (а может и более специфичных для конкретных задач) с специфично натренированными нейросетями, хоть до того же копания угля, на самом деле уже рукой подать.
Ещё думаю многие компании старого толка просто работают по инерции старыми методами. Новый конкурент или новый управленец — и может внезапно оказаться, что и тут современная автоматизация справится куда лучше и быстрее людей.
Тогда уж и ещё одно замечание для справедливости полной — сейчас даже и без государства, — корпорации имеют кучу вариантов убить что угодно ради собственной прибыли, пусть даже это «что угодно» на деле давало бы только пользу и развитие человечеству.
Не, конечно на определённом этапе новый общественный строй, капитализм, был прорывным и дал свои немалые плоды. Но в наше время не покидает уверенность, что он уже полностью уныл и deprecated. Только тормозит да палки в колёса вставляет, попутно занимаясь эксплуатацией людей и «макроэкономическими операциями» в формате вплоть до войн за сотни нефти, за которые можно получить деньги.
До нормального социального общества боюсь мы тоже до сих пор всё не доросли.
Основные надежды сейчас на логическое завершение тихой промышленной революции — когда роботы и искусственный интеллект заберут 99,99% рабочих мест, образовав практически полностью самообеспечивающую себя и обеспечивающую всем необходимым людей техносферу, а как следствие, невероятное количество людей окажется без работы. Хочешь не хочешь, а старый общественный уклад будет неприменим.
С другой стороны, судя по развитию отечественного ИТ 1990х-2010х — вот действительно, лучше прогресс в отрасли идёт, когда государство не заинтересовано и никак не трогает.
Вот и я тоже. Кто там умер, ничего не понятно. Моей версии винампа, которой пользуюсь уже лет 15, ничего не мешает, — прекрасно работает и выполняет свои функции. Это собсно ключевая мысль. Ну и кушает мало-мало, это прекрасно.
И конечно только винт, никаких онлайнов и облаков, чур чур. Ну разве что радиопоток включить с какой-нибудь интересной вещающей в сеть радиостанции.
Можно конечно меньше разогреваться, 400 или 300 (на моём железе хватало вполне), но зачем, если практически каждый уровень разбирается примерно за 400 ходов.
Получаю 8451 очков на финальном сете (правда на моём проце) и 6-е место. Но это ж он минуту целую стоит и курит. Сколько раз его за это время могли лопатой по голове стукнуть в случае двух игроков. =)
Да, конкурс получился на славу!
А вообще, как насчёт формата следующего игрового конкурса с двумя машинами и взаимодействию по JSON API?
На одной сервер, реализующий это API, с игрой, которая (возможно, после обмена синхронизационными запросами) по команде старта от клиента или же самостоятельно, отвечая клиентам статусом со временем предстоящего запуска, начинает свой неумолимый ход жизни мира с метрономскими тиками.
На другой машине — игровой клиент, который будет это API использовать. Пытаться управлять своим игроком в этом мире, пытаясь набрать счёт.
Синхронизация решается достаточно просто, были б таймстампы в соотв. методах API.
Независимость работы машин очевидна.
В случае параллельной игры нескольких игроков в равные условия все могут быть легко поставлены, когда клиентские машины с решениями, например, размещаются в одном и том же ДЦ. Можно заодно устранить значимую часть лагов, поместив их в тот же ДЦ, что сервер, а можно в другой и сделать из (умеренных) лагов фишку.
На мой взгляд может получиться очень, очень интересный челендж, лишённый многих проблем одномашинного запуска и очень приближенный к боевым условиям.
Да и хотел изначально сделать более приближенного к реальности бота — конкретные условия конкретными условиями, но всё же, блин, карта может в реале быть иного размера, игрок может находиться в нескольких клетках под падающей бомбой или в нескольких клетках на пути ножниц… то есть бабочек, и ему нужно бежать, бежать, сразу бежать. Или может если он будет стоять то упустит возможность сожрать какие-то близкие алмазы, пока всё изначально падает-бежит в уровне и всё такое.
Так что сейчас в предварительных результатах моё 7-е чудо тоже бежит сразу с места стартуя и размышляя на ходу. И доступное процессорное время в тике для него решающе важно. Ридми не делал, зато с именами переменных порядок, комментарии семантические присутствуют и всё такое.
А что касается дела — так всё равно нас обманули :) Обещали, у вас будет 100-мс-минус-одна-пикосекунда на размышления о следующем ходе, но нет.
А каким образом это может быть связано с энергосбережением (опять же при учёте что мы фактические тайминги измеряем)? Процы на экспериментальных системах имели по более чем 2 физических ядер и не были заняты ничем иным.
Честно говоря, эти странные непредсазуемые пропуски хода в воркер режиме полсилы решения отправили в ведро. =/
Уже при 50мс начинались значимые случайные… сбои синхронизации? Что-то начиналось. Даже при 40мс иногда. И бот ловил внеплановый пропуск хода, после чего остальные продуманные им ходы летели в печь. И из-за нестыковки того, какой он думает сейчас фрейм и какой в действительности фрейм, происходило вот это вот долбление о стены, умирание под камнями и прочее подобное.
PS: Ну и если, вдруг, тестирование будет решено производить в формате -p с контролем уже общего времени работы процесса игры = 120 +- 1 секунд (чтоб решения ну не могли «тупить» в зачёте) — то было бы вполне справедливо поправить решениям настройку «сколько можно думать» со слишком урезанных таймингов до 80мс. Наверняка такая настройка есть у многих вариантов. Или, не знаю, дать всем какой-нибудь «вторник допиливания», о котором объявить завтра. … Ну или оставить как есть, честно не знаю.
Просто в однопроцессном (-p) режиме не было никаких проблем, когда разрешал считать своему 80 мс из 100, зная, что возможное лишнее время от разрешённых 80 мс не уйдёт более +5..10 мс. Но в «боевом режиме» такой формат обсчёта приводил к непредсказуемым пропускам хода (при этом никаких явных вылетов за разрешённые рамки не было), и для стабильности пришлось урезать доступное время расчёта до, блин, 30 мс из 100.
Не знаю, может что делал не так, но очень неприятный момент, и не совсем понятно, что же именно мешает при запуске в воркер режиме.
А суть кода главного цикла примерно такая:
где ai.frameCalcTimeout пришлось ставить 30 мс.
Признателен, если кто-то пояснит, в чём тут может быть проблема, и как «вернуть» в пользование время порядка 80-90мс из 100.
Ещё думаю многие компании старого толка просто работают по инерции старыми методами. Новый конкурент или новый управленец — и может внезапно оказаться, что и тут современная автоматизация справится куда лучше и быстрее людей.
Тогда уж и ещё одно замечание для справедливости полной — сейчас даже и без государства, — корпорации имеют кучу вариантов убить что угодно ради собственной прибыли, пусть даже это «что угодно» на деле давало бы только пользу и развитие человечеству.
Не, конечно на определённом этапе новый общественный строй, капитализм, был прорывным и дал свои немалые плоды. Но в наше время не покидает уверенность, что он уже полностью уныл и deprecated. Только тормозит да палки в колёса вставляет, попутно занимаясь эксплуатацией людей и «макроэкономическими операциями» в формате вплоть до войн за сотни нефти, за которые можно получить деньги.
До нормального социального общества боюсь мы тоже до сих пор всё не доросли.
Основные надежды сейчас на логическое завершение тихой промышленной революции — когда роботы и искусственный интеллект заберут 99,99% рабочих мест, образовав практически полностью самообеспечивающую себя и обеспечивающую всем необходимым людей техносферу, а как следствие, невероятное количество людей окажется без работы. Хочешь не хочешь, а старый общественный уклад будет неприменим.
И конечно только винт, никаких онлайнов и облаков, чур чур. Ну разве что радиопоток включить с какой-нибудь интересной вещающей в сеть радиостанции.