Про API дизайн

Этот пост меня побудила написать интересная статья на хабре. В ней автор рассказывает на интересных примерах как строить грамотный API своего кода. 🤔

Я, надо бы сказать, побывал уже в большом разнообразии стадий построения решений. Когда-то я писал программульки просто так, чтобы они работали.💃 Потом я познакомился с замечательными патернами и, конечно же, оверинженирил по полной. Сегодня я уже могу просто сидеть по несколько часов просто чтобы сделать неплохой дизайн. Ключевое здесь — "неплохой", потому что я знаю, что можно делать лучше и я вижу это в других решениях. 🤓

Когда я начинал свою деятельность, требования для меня были шуткой и что-то из разряда: "профессионалы этим не занимаются, это скучно🤪". Потом ты становишься этим профессионалом и понимаешь, что всё же все эти требования очень важны, причем настолько, что клацание по клавиатуре в попытках написать очередную функцию практически происходят незаметно. Мне каждый день приходится решать задачи, связанных с уточнением и реализацией требований, т.к. у нас достаточно сложный ML сервис. И если честно, я больше сижу и думаю про то, как это сделать хорошо, а пишу код потом уже очень быстро.🔼

Но всё это лирика, давайте к практике. Первое, что вы всегда должны понимать, когда начинаете разрабатывать: "когда я буду использовать этот код еще раз?". Скорее всего, если вы MLщик и пишете очередную функцию для агументации, фитпредикта, трейнлупа, которые вы хотите просто быстро написать чтобы запустить эксперимент и проверить гипотезу — вам не нужна никакая архитектура. Если хотите работаете в jupyter notebook, пишите скрипт для переименования файлов, мерджа картинок, заливки данных и прочих "простых" инструментов — вам не нужна архитектура.🙃

Приведу пример: когда-то я писал скрипт для загрузки данных на сервак. У меня в голове сразу 3 идеи: можно сделать в одном потоке, в нескольких процессах, асинхронно. Данные исчесляются десятками миллионов картинок, а потому в любом из этих вариантов скрипт будет работать ну долго. Просто в случае одного потока это вся ночь, в случае мультипроцессинга — полночи, а асинхронность даст еще 20% ускорения от мультипроцессинга. Вопрос: что выберешь написать? 😂

Ответ: конечно же однопоточную загружалку. Вероятность того, что в однопоточном режиме что-то сломается, крайне мала: я точно не создам ддос сервака, я точно не открою бесконечное количество файловых дескрипторов (хотя эти случаи все равно стоит обработать). В случае мультипроцессинга или асинхронности все это дело надо еще хорошо отладить, убедиться что оно работает, проверить корректность загрузки и т.д. По итогу получается, можно просидеть полдня над решением побыстрее, или полчаса над решением полегче (которое в один поток). Но результат один и тот же — я поставлю скрипт на ночь и пойду спать 🙂 Только до этого в случае простого решения я сделал несколько других задач, а в случае мультипроцессинга дай бог завершил текущую задачу и пошел в бар созидать бесконечно вечное.

Когда ты строишь production-like решение, пишешь библиотеку, или другими словами делаешь решение "на века", тогда здесь без дизайна не обойтись 😔. Нет, ты конечно можешь быстро что-то написать, упустив половину требований, написав в названии "MyBestFunction", но тебе потом жить с этим (где-то сейчас заплакал человек, внёсший std::vector<bool> в стандарт).

И вот, к сожалению, часто я вижу картинку, что всё наоборот. Когда надо делать хорошо, там всё плохо, а когда не надо, там человек старается и пыхтит. Что тут сделать, как исправиться? 😮 Учиться у профильных коллег. Если ты МЛщик, разраб, девопс, да кто угодно и хочешь научиться писать хорошо API (а это нужно делать, чтобы как минимум по грейду расти), читай код работяг, пишущих сервисы пососедству, приходи к ним и узнавай, почему сделано так, а не по другому. Как говорил классик: "делай это упражнение 2 раза в день, и..."

Плата за плюшки

Наткнулся на короткую заметку про то, как можно легким движением ускорить std::vector::push_back на 10%.🔼

Сначала автор рассказывает, что если создать vector и пушить в него значения — то моя программа будет супер медленной. Для ускорения предлагается использовать reserve, который увеличивает capacity контейнера. И это действительно верное утверждение, особенно если заранее известно количество элементов, которое будет вставлено. В противном случае, при достижении capacity на очередном (но не обязательно финальном) вызове push_back, будет произведена аллокация большего куска памяти, в который сначала переместятся элементы из старого куска памяти, а потом вставится новый элемент. Как ты можешь понять, это будет ну очень долго😐.

Но дальше автор рассуждает: если я резервирую память на заранее известное количество элементов, то имеет ли смысл делать проверки на превышение capacity, если я условно гарантирую такое количество вставок, которое не превысит заданный предел? И вот оказывается, если я напишу альтернативный метод push_back, но без проверок — вставка начнет работать на 10% быстрее. Однако, утверждает автор, если я нарушу контракт и начну вставлять больше элементов, то новая функция будет иметь UB, что очень больно 👨‍🦳.

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

Неужели твой и мой код медленные, модельки можно обучать и инферить быстрее? Да, конечно 🙃! Но посмотри, что мы от этого получаем? Удобные интерфейсы для подготовки пайплайнов, прототипирования моделек и прочих радостей жизни. Давно ли ты что-то писал на TF? Я не думаю😂. Зато как ты любишь Pytorch (и не говори, что нет). Однако, на моей практике, хорошо собранный пайплайн на TF итерацию forward-backward path выполняет быстрее Pytorch, а также занимает меньше памяти. Но совсем незначительно (как и в примере с std::vector), в сравнении с тем, как неудобно этим делом пользоваться.

Или же вспомни классическое нахождение опеределителя матрицы 3х3 🤓. Можно пойти через правило треугольников и получить формулу, которая вычисляется за 12 умножений и 5 сложений. Правило простое и интуитивно запоминается, на экзамене вспоминается чаще. Другой разговор про нахождение определителя через разложение на миноры. Там нужно и матрицу знаков помнить, и вообще что такое миноры, и как у них определитель находить. Но при этом вычисления всего лишь за 9 умножений и 5 сложений. И ничего себе, я вроде как сохранил 3 операции, но какими усилиями.

Потому я всегда думаю при реализации, а какими удобствами могу пожертвовать в угоду эффективности работы приложения. Это отражается и в коде, и в идеях, которые я закладываю при создании той или иной функциональности👨‍💻.

Немножко о себе

Привет! Меня зовут Антон! В этом блоге я пишу про свои похождения в мире IT, делюсь рассуждениями по различным топикам из интересующих меня областей. Вот часть из них:
👨‍💻 С++, Python
🤓 Deep Learning в целом, CV в частности
🔼 Оптимизация вычислений, ускорение чего бы то не было
💃 Управление командами
😐 Эффективность, тайм-менеджмент и прочая эзотерика.

Сейчас я работаю Senior MLE в Яндексе. Занимаюсь развитием технологий распознавания текста на изображениях (OCR). Обычно я представляюсь как "разноработчик" 🙃, потому что занимаюсь далеко не только ML, но и всякими интересными штуками в продакшене. Я большой фанат разработки, дико обожаю когда решение ускоряется в десятки и сотни раз, а также всегда топлю за лаконичные решения. Моя страсть — это мемы, а также холивары про то, как делать что-то лучше в IT 😂.

Органичный рост в командах разработки 🔼

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

Но вот что самое интересное — это 3 инженера 😮. 3 инженера делали сервис, который в пике на тот момент достиг 14 млн пользователей. Часто ли ты такое встречаешь? Я нет.

Проблема разработки, которую я часто вижу в различных компаниях, которой грешат даже очень популярные люди в индустрии: заливаются все проблемы людьми, невероятно быстро выращивают отделы😔. И все это в надежде выпускать фичи в кратном объеме, чинить баги и пр. Но такой неорганичный рост превращается в разные проблемы, которые не решают поставленные задачи:
1. Думали, что 50 людей == 50 фичей, а получили 10 😐. Потому что чем больше людей, тем больше согласований на разных уровнях, и это затягивается. А также возникает очередь из ожидающих разработчиков, потому что из деятельность просто заблокирована;
2. В условиях быстрого роста очень сложно привить культуру компании, а у каждого свои цели, амбиции и желания, которые влияют на принимаемые решения🤔.

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

А что думаете вы об этом всём🤔?

Помоги компилятору стать лучше

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

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

Перессказывать доклад не буду, но мне очень понравились рассуждения спикера в конце😊:
— Не нужно оптимизировать там, где это не нужно. Оптимизируй действительно важные и горячие места, в этом тебе может помочь разные инструменты для анализа перфоманса;
— Иногда компилятор может "сказать" тебе, почему он принял то или иное решение, и если у тебя достаточно скилов понять его, ты можешь ответить ему в виде инструкций, часть из которых описаны в докладе, и помочь сделать итоговый бинарь лучше🔼.

И как же я с ним согласен. Я сам пишу код на C++ не так часто, а потому знаю меньше людей, которые пишут на C++ каждый день. Я очень часто забываю даже очень тривиальные концепции из языка. Но вот правило "не суй, если не знаешь зачем тебе" со мной навсегда. Прежде чем заиспользовать какие-то хитрые или около того конструкции, я всегда подробно изучаю насколько "ок" это сделать 🙃.

Что самое жестокое, что иногда в практике на вопрос "зачем так сделал?" получаю ответ "ну вроде же прикольно получилось" 😑. Вот вообще не прикольно, нет.

Немного анонсов с работы ☺️

Сначала подумал, чтобы написать пост про каждое из событий отдельно, но потом решил, что в этом нет особого смысла, лучше позже расскажу про интересности с constexpr. В целом, это лично моя инициатива, потому что я всегда горю тем, что делаю, и очень заинтересован в развитии сервисов, команд и компаний 🙃. Так что не судите строго.

Я решил поучаствовать в рабочей группе трека ML в рамках Yandex Cup. Вместе с большой командой готовим для вас соревнование. Приходи участвовать, будет весело (иногда сложно и больно 👨‍🦳). Призы в целом тоже кайфовые. Ну и мне тоже будет приятно!

Я в СПб ищу себе стажера, с которым будем решать нескучные задачи OCR, в первую очередь связанные оптимизациями нейронных сетей (как по объему, так и по скорости исполнения) 🔼. Если тебе уже знакомы слова Python, C++, Pytorch, Tensorflow, Git и на практике успел пошаманить с нейронками — приходи, пообщаемся!

Ну а если ты уже имеешь рабочий опыт в CV или NLP, можешь рассказать моей бабушке, что такое трансформеры 😃 и любишь решать нестандартные и очень хардкорные задачи, приходи пообщаться по поводу позиции в штат!

И если тебе не сложно, поделись с другом, мало ли он что-то захочет из этого списка 😁!

constexpr родимый

Чтобы ты понимал, почему C++ — это сложно, просто вспомни про ключевое слово constexpr 👨‍🦳. Про него все знают, его все уважают, но мало кто использует. Почему? Не знаю. А он есть. С C++11 🙃.

Недавно читал статью про то, как влияет constexpr на размер бинаря. Автор проводит несколько тестов где:
— Сравнивает одну и ту же функцию без и с ключевым словом constexpr;
— Делает сначала тесты с одной единицей трансляции, а потом с несколькими; причем на нескольких два вида сборки: сборка сразу всех файлов в один бинарник и сначала сборка файлов по библиотекам, а потом линковка вместе.

Результаты чарующие 😧: практически нигде нет профита между функциями без constexpr и с ним, кроме одного случая — где сборка сначала происходит в библиотеки, а потом происходит линковка. Там профит почти на 30%...😳

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

constexpr functions and constexpr constructors are implicitly inline.

Чтобы функция в хедере была аналогичной, я вместо constexpr писал inline. Но как ты можешь увидеть из сноски выше — в плане разрешения имен это одно и то же (напомню, что inline это ключевое слово, которое позволяет сделать исключение из ODR и сделать одно определение на все единицы трансляции). Потому заявленное свойство constexpr — это свойство inline 🥲. И как автору в сборке с "профитом" удалось сделать это самое улучшение — я не понял. Если кто знает, помогите 🥺!

Но всё же одна плюшка (кроме основной — возможное вычисление в compile-time) мне понравилась: можно зафорсировать вычисления констант, а это позволяет избегать штуки, по типу деления на 0 ☺️.

Смешное про С++

В рамках подготовки к семинарам по C++ для студентов ШАД я в обязательном порядке повторяю материалы из большого количества источников 😊 :
— мои личные заметки;
— лекции лектора, чтобы понимать, о чем говорить на семинаре;
— различные ролики на youtube от известных спецов.

И вот я досматриваю очередной ролик, смотрю в комментарии, а там просто очень классная переделка всем известной песенки 😂:

Аа, в C++ указатели на память вот такой ширины,
Аа, в C++ шаблоны классов вот такой вышины,
Аа, прострелянные ноги,
Аа, нам с UB не по дороге,
Аа, и no more попугай,
Аа, и expired попугай.

Про попугая здесь отсылка к известному скетчу, упоминаемому в рамках лекции в разговоре про провисшие ссылки (возвращаем или/и используем ссылку на уничтоженный объект) 🤓.

Про цели, время, работу, славу

В октябре выдалось много работы 🙃. Собеседования ребят на проект в ШАДе, семинары в ШАДе, личный менторинг, завершение старых и старт новых проектов на работе. Кажется, немного, но хватает, чтобы иногда не спать сутки.

Я слышал недавно фразу: "если вы целыми днями работаете, то у вас нет времени менять этот мир." Звучит с одной стороны разумно, а с другой стороны — удел ли каждого менять мир? Явлется ли это моей целью? Или твоей? Решать каждому. Но звучит очень громко — поменять мир 🤔.

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

🔼 Например, Рентген открыл одноименное излучение, просто случайно заметив. Но мало ли он проводил в лаборатории времени?

🔼 Ну или более хайповая нынче тема с LLM (aka ChatGPT), где ребята из OpenAI решили попробовать, а что если обучить модель с большим количеством параметров на большом количестве данных. В итоге нашли удивительные свойства этого семейства моделей.

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

Ставить как цель получить какую-то славу или успех лучше не стоит. Это очень абстрактно. Ставить цель ради цели также бесполезно, вы будете думать больше о ней, чем о реальных делах 😔. Отвяжитесь от себя, если не можете поставить цель — это нормально. Мне кажется в этом мире, дико перегруженном методиками продуктивности, стоит просто не забывать кайфовать от работы, себя и жизни ☺️.

А если вы любите своё дело, всё придет — и слава, и мир поменяете 🔼. Ну а если нет, то возможно оно вам и не нужно было 😐? Как минимум у вас уже есть своё любимое дело ☺️.

Проект с нуля

На днях с коллегой общался на тему: как стартовать проект с нуля 🤔. Мне был интересен сам фреймворк принятия решений на основе накопленного опыта. Здесь опишу кратко свои мысли после всей нашей беседы.

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

Во-вторых, твоя позиция в проекте может быть разная 👨‍💻. В каком-то случае, ты сам себе программист, дизайнер и проджект, а в каком-то ты стараешься сделать так, чтобы верстка на фронте не поехала. Разница лишь в том, как много контекста нужно держать для решения задач. 🤪

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

Я уверен, что можно писать бесконечно этот список, но я был удивлен, что в целом принимать решения во всем этом многообразии можно примерно одинаково 🙃:

1. Ты понимаешь что нужно делать, чтобы запустить проект прямо сейчас? 🤔
2. Если да 💃, то поздравляю, ставь таски, часть делегируй, часть делай.
3. Если нет 🤔, обратись к одному из своих инструментов декомпозиции задач и по каждая задача становится мини проектом. Вернись в п.1 и повтори алгоритм.

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

А пока ничего сложного! Хотя... "инструменты декомпозиции задач" странный термин 🤓. Но в какой-то мере он может определять ваш опыт. Потому что важно не только про них знать, но и уметь их использовать.

Про эти инструменты я, пожалуй, напишу уже в одном из следующих постов!😁

Runway. Motion Brush in Gen-2

Офигеть 😮. Просто не надо слов. Смотрите демку. Если будет так (это видосик из анонса) — это будет невероятная фантастика.

Ребята обещают запилить кисточку в своем редакторе, которая приводит в движение выделенную область на картинке. Да 🙃, это делали и до этого, но если в таком качестве — то вроде никто.

Да, я понимаю, что артифакты есть и они будут. Но если у вас динамичный продакшн и вам нужно на секунду показать какую-то динамику — то это просто шикарнейший инструмент 🔼.

MusicGen

Не особо слежу за развитием AI в области генерации музыки, но тут мне попался под руки релиз от одной экстремистской организации 🙃.

Подход позволяет создавать стерео-музыку из текста 😮. Условно задаешь ей такое:
A grand orchestral arrangement with thunderous percussion, epic brass fanfares, and soaring strings, creating a cinematic atmosphere fit for a heroic battle.

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

На секундочку замечу, что это все же стерео 🔼. Еще года 3 назад я с коллегами обсуждал, что вот бы сетки научились делать качественное музло в моно канале, а тут такое!🤨 Понятно, что это не Моцарт, но все же.

А еще на вход можно подавать аудиозапись, и тогда сетка извлечет стиль исполнения из неё и использует эту информацию для генерации аудиотрека 🤪. Я воспользовался этой возможностью, и попробовал для промпта выше сгенерировать что-то на мотивчик интерстеллара (вот такой пример брал). Получилось неплохо (слушать тут) 🤨!

Также попробовал еще другой запрос для интерстеллара:
a rap bit with piano, violin, heavy drums, slight kick and aery pads, 96 bpm, perfect for a commercial
Ну и этот вариант мне понравился еще больше (слушать здесь) 💃!

Из ограничений: демка генерирует только 15 секунд, но если хочешь больше, то нужно уже хостить самому или попробовать запустить в коллабе. Также она не работает с вокалом 🤔, работает далеко не с первой попытки 🤔.

Под капотом лежит трансформер 🤓, который работает с текстовыми и аудио токенами. Разбор статьи делать не хочется, поэтому если интересно, можешь прочитать здесь ☺️.

Методичка: Поиск Работы в ML/DS

@boris_again Написал классный гайд по поиску работы 😮. Я бы не сказал, что это только для ML/DS. Скорее в целом, для технических специалистов 🔼. Дальше по тексту из поста:

Все кратко и по делу. Чтения минут на 30. Внутри рассматриваю поиск работы с самых азов и до деталей с примерами из жизни.

https://btseytlin.github.io/intro.html

В общем, однозначный лайк!☺️

Распознавание жестов

Однажды у моей в команды была замечательная задача — нужно было сделать распознавание жестов 😃. Требования были простые: RPi 4B, CPU only инференс, максимальная задержка на кадр — около 30 мс, сами снимики были чб. На тот момент самым популярным готовым решением был mediapipe — просто берешь распознавание скелета руки, накидываешь сверху постпроцессинг ключевых точек, простой классификатор — и решение готово. Ну или почти готово...👨‍🦳

Пайплайн детектирования ключевых точек ладони в фреймворке устроен следующим образом:
1. Сначала отрабатывает детектор ладони (который не совсем тривиальный);
2. Затем происходит поиск ключевых точек на кропнутом изображении ладони.

Обычно ладонь имела ориентацию вверх, т.е. ладонь как-то поворачивали. Для этого использовали ключевые точки, которые находились вместе с детектором второй головой 😵‍💫. Поэтому обучение такого детектора — не совсем классическая задача детекции.

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

Проблема вторая: код исполнялся примерно за 70-100мс на запрос. Это было очень много 🤨. Ну как бейзлайн решили использовать post-training квантезацию. Сначала были проблемы с качеством, но путем подборки хорошего калибровочного датасета всё решилось. Но вот со скоростью стали проблемки. 100мс+ на запрос, что больше даже без квантезации. Как так 🤔?

А все просто. Где-то внутри кишочков XNNPACK после долгого лютого дебага обнаружился баг, который некорректно обрабатывал свертки. История в github показала, что на тот момент ребята из команды этого фреймворка только её решили и еще даже не положили в релиз 👨‍🦳. Мы попробовали и о чудо: каждый запрос до 30мс, а я замечу что тут была еще наша классификационная голова 😅.

Это вот я вам рассказываю так легко сейчас, а тогда было сложно. Ни нормальной документации, ни порядочных примеров. Но мы справились. В целом, задача вышла достаточно инженерной, в тот момент я прям кайфанул от результатов. Сейчас наверное тоже бы ☺️.

Я еще хотел рассказать про сам mediapipe и как он хорош, но пост уже и так большой. Как нибудь в следующий раз.🙃