Разработчик: интерфейс приложения интуитивно понятен, с ним справится любой пользователь
Пользователь:
https://www.youtube.com/watch?v=JLuzjlRsrVQ&ab_channel=niggacommunist

В теории чисел есть важная теорема под названием "Квадратичный закон взаимности". Как и многое другое в математике, его открыл Эйлер; как и многое другое в теории чисел, его доказал Гаусс, в 1801 году.

(если у вас есть два простых числа p и q, этот закон объясняет связь между "найдется целый квадрат, который дает p в остатке при делении на q" и "найдется целый квадрат, который дает q в остатке при делении на p", поэтому "взаимность")

Гаусс так полюбил этот закон, что придумал шесть разных его доказательств. То, которое он нашел первым - самое сложное и запутанное. Оно занимает пять страниц текста, в зависимости от чисел p и q рассматриваются восемь разных случаев, у многих из этих случаев есть под-случаи, а в одном особенно коварном случае один из под-случаев разбивается на четыре под-под-случая.

Кто-то пошутил и назвал его "доказательством методом математического омерзения".

Интересная статья про Рамануджана на хабре, советую: https://habr.com/ru/company/wolfram/blog/306250/

Из истории создания курса теоретической физики Ландау и Лифшица: Замысел всеобъемлющего курса теоретической физики возник у Л. Д. Ландау и М. П. Бронштейна ещё в конце 1920-х годов в ленинградском Физтехе. Они независимо продолжали работу над ним в 1930-х (Бронштейн в Ленинграде, а Ландау в Харькове), однако в 1938 году Ландау был арестован, а Бронштейн расстрелян.

Как же я обожаю истории из СССР первой половины 20 века...

О воркерах в @RoundDFBot.

Кто такие воркеры?
Это эдакие микросервисоподобные скрипты на питоне, которые занимаются обработкой видео с помощью нейронки. Они общаются с главным сервером по HTTP. Берут себе задание, скачивают нужные файлы, обрабатывают их, загружают результат и отчитываются о готовности.
Плюс такой архитектуры в том, что она хорошо масштабируется горизонтально, то есть мы можем легко подключить как 2 воркера, так и 20.

Почему на питоне?
Потому что нейронка на питоне, почему же ещё.

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

Почему на каждом сервере запущено по 2 скрипта?
Потому что один скрипт не может ипользовать все ресурсы в одиночку. Я почти уверен, что дело тут в GIL, но разбираться с этим пока что слишком нецелесообразно. Как показал эксперимент, два скрипта рядом выдают большую суммарную производительность, чем один. Даже несмотря на то, что каждый из скриптов работает медленнее. чем мог бы в одиночку (например, 200+200 вместо 300)

Хорошая новость:
Мне удалось запустить воркер @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

лучший мерч