Хорошая новость:
Мне удалось запустить воркер @RoundDFBot в Google Colab. Это оказалось куда проще, чем я предполагал. По производительности достаточно хорошо: чуть мощнее моего компьютера с 1660ti, примерно как половина среднего сервера на vast.ai.

Плохая новость:
За 1.5 дня у меня исчерпался лимит на GPU инстансы.

Стефан Банах — это монетка в два злотых, шутка с капустника про царство хана Банаха и, конечно же, теорема о неподвижной точке . В своё время на меня большое впечатление произвела её наглядная интерпретация. Берём большую карту Москвы и расстилаем на полу. Затем берём маленькую карту Москвы и кидаем её на большую так, чтобы она полностью на ней уместилась. А теперь можно взять гвоздик и проколоть обе карты по одному адресу

Спасибо, правительство, за новый закон о предустановке софта российского производства с 2021 года
https://www.rbc.ru/technology_and_media/23/11/2020/5fbb84ff9a79477365cf529d

Кажется, нам опять под сомнительным соусом протекционизма всунули что-то

От скуки переписал метод получения заданий во внутреннем API @RoundDFBot по принципу Long Poll.

Вот тут можно почитать чуть подробнее, что это такое.

Раньше у меня был реализован банальный short poll: раз в 3 секунды воркер спрашивал у сервера, есть ли подходящее задание для него. Ответ приходил мгновенно: задание либо есть, либо нет.

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

Чем это лучше?

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

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

Самое интересное: в-третьих, теперь я могу более детально настраивать очередность получения заявок.
Могу по простому принципу: очередь (первый пришел — первый ушёл), стек (последний пришел — первый ушёл) или как-нибудь ещё.
А могу сложнее: днём отдавать моему компьютеру больше заданий (потому что это дешевле по сравнению с другими воркерами), а ночью наоборот меньше (чтобы не шумел и не мешал мне спать)😉

психолог: доктор Дре и Снуп не занимались матаном и не записывали альбом с интегралами
доктор Дре и Снуп:

✨ О войне с GIL'ом

Самая первая версия воркера работала в один поток: сначала видео читалось в память, потом кадры обрабатывались на нейронке, потом готовые кадры склеивались в видео. Но это было неоптимально: во время первой и третьей фазы видеокарта простаивала, а ведь она являлась главным ресурсом.

Поэтому на следующий день после релиза мы улучшили архитектуру: выделили каждую фазу в отдельный поток и запустили их параллельно. Теперь, пока одна заявка обрабатывалась на нейронке, следующая могла проходить препроцесс. Таким образом удалось уменьшить время простоя видеокарты, но появилась другая проблема: во время работы потока с препроцессом производительность нейронки заметно падала (потери составляли примерно 50%). Когда препроцесс заканчивал свою работу, всё возвращалось в норму.

Это происходило из-за GIL'а (Global Interpreter Lock). Проще говоря, интерпретатор питона исполняет код только в одном потоке, а остальные ждут. Раз в некоторое время интерпретатор может переключиться на другой поток. В этот момент предыдущий ставится на паузу, и так далее. Поэтому питон не может оптимально выполнять два "тяжелых" действия в разных потоках. Они начинают конкурировать за процессорное время и терять в производительности. Если хотите узнать об этом подробнее, зацените эту статью на хабре. Она довольно старая: за это время вышли новые версии питона, в которых, возможно, добавили некоторые оптимизации, но общие концепты всё ещё актуальны.

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

Но в последние несколько дней я ещё раз активно поэкспериментировал с мультипроцессингом, и это, кажется, дало свои плоды. На этот раз я вынес в подпроцессы препроцессинг и постпроцессинг, а нейронку оставил в главном. И просадки исчезли! Теперь мы можем запускать по одному скрипту на сервере.

Я попробовал ещё несколько оптимизаций (например, сделать два потока с нейронкой), но это не дало положительных результатов. Поэтому пока что остановимся на такой архитектуре.

Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как нейронки становятся все лучше и лучше. Новая модель от исследователей из Вашингтонского университета и Фейсбука умеет анимировать статичные фотографии с огонем, водой, дымом и паром.
Официальный сайт
Статья на архиве
Код is coming soon

лучший мерч