C++ для самых маленьких 😄 и С++ для тех, кому за 300 😢

В последнее время нет сил что-либо писать. Да что уж там говорить — нет сил что-либо делать. Какое-то эмоциональное выгорание, которое я никак понять не могу 🥺. Но между делом я стараюсь уделять время своему любимому хобби — программированию 👨‍💻.

Совсем недавно я наткнулся на конспекты курса по C++ кафедры КТ (компьютерные технологии) Университета ИТМО 🧑‍🎓. Они в целом хороши — дают первичное понимание языка, того, как это работает и что с этим можно делать. Жаль, что мемы не вставили — тогда был бы лучший курс для самых маленьких 🍷, имхо.

Сейчас я погружаюсь детальнее в то, как работают приложеньки на Unix-подобных системах. В частности, как они загружаются в оперативку, как находят сторонние зависимости и т.д. Казалось бы — при чем тут C++, а на самом деле есть повод задуматься😢. Мы можем оптимизировать поиск сторонних зависимостей (как во время компиляции, так и во время исполнения), можем оптимизировать загрузку в оперативку. А это все сказывается на пользовательское ощущение от использования наших приложений (вас же тоже бесит то, как долго грузится spotify или slack??? 😡).

Куда важнее ситуация, когда мы делаем приложение на highload backend 😆, где важно не только время на ответ, но и также, как быстро приложение может восстановиться после падения. Поэтому понимание того, как работает наше приложение от момента нажатия на enter — очень важно, и классно, когда мы можем управлять этим процессом на своем языке программирования.

"Я как будто бы уже давно глубокий старец, бессмертный, ну или там уже почти бессмертный" стараюсь изучать эти процессы, чтобы делать мои приложение быстрее, лучше. Я "ищу только одного — покоя, умиротворения и вот этой гармонии, от слияния с бесконечно вечным, от созерцания великого фрактального подобия и от вот этого замечательного всеединства существа" 😄.

Новая эпоха 👨‍💻

С сегодняшнего дня я сотрудник компании Яндекс. Буду помогать команде улучшать качество сервисов, применяя свои знания в области CV DL и C++.

Думаю, будет много интересного, чем можно будет в том числе и поделиться с вами! А пока буду вливаться в процессы :)

Первая неделя 😆

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

Но на удивление, я уже почти втянулся 😳. Понятное дело, что всё равно еще кучу всего узнавать, но скажем так, я немного освоился. Уже ясно, какие основные сервисы, куда зачем и почему писать. Это, конечно, не только моя заслуга, но и целой команды Яндекса, которая построила процесс onboading с одной стороны, достаточно емким по знаниям, с другой стороны достаточно легким для понимания 🙏 (если что, это не реклама, просто мне понравилось).

Удивительно, но за эту неделю я также успел уже полазить в коде, посидеть на проде 👨‍💻. Каждый раз волосы встают дыбом, когда понимаешь, какие мощности сосредоточены в этой компании. Я думаю, это пройдет, но пока я прям очень восхищаюсь 🤨.

С такими мощностями также приходит и отвественность: под большими нагрузками нужно делать надежные сервисы. При этом стараться делать решение как можно быстрее и без потерь качества 🔼.

Давайте договоримся, если за недельку ничего WOW не произойдет, я расскажу в следующем посте про Modules — относительно новая фича из C++20, которая в некотором роде "упитонячивает" C++. Честно говоря, я еще особо не разбирался — но кажется настало время! 👵

(E)Sim

Вы мне тут скажите — Антоха, подожди, ты же вроде про модули хотел написать 🤔. Это правда — хотел, но пока я с ними разбираюсь. Там такие костыли приходится городить, а вам хочется донести самую мякотку 😇.

Итак, о чем тут это мы. Я тут недавно задумался, что у меня на телефоне есть esim — погуглил и вроде даже в РФ можно её сделать очень просто (по крайней мере у МТС). Начал читать чего и как и наткнулся на сайте МТС на фразу:

SIM (Subscriber Identity Module) — это не просто идентификационный модуль абонента. В нём есть 10 МГц процессор, постоянная энергонезависимая память (а питание для работы SIM берёт от смартфона), контроллеры и даже собственная операционная система.

И тут я прифигел. В смысле, симка — это миникомпьютер 🤯? А что, так можно было???

Оказывается это правда. SIM в нашем понимании — это симка для телефона. В реальности, эту технологию применяют еще много где (даже на наших банковских картах). Естественно, что софт у банковских и мобильных симок отличается. Как минимум приложения (вы вдумайтесь, приложение на симке!!!) для идентификации у каждого провайдера свои. 😏

Но я не скажу больше, чем написано в этой статье на хабре. Поэтому приглашаю почитать! 🙈

Качество кода

Кто меня давно знает, тот понимает, какой я фанатик по качеству кода 💃. Я смотрю на качество не только с точки зрения "красивости", но и с точки зрения менеджмента: что это дает мне и моим командам 😇.

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

Под хорошим качеством я обычно подразумеваю не только стиль кода и покрытие тестами, но и:
— наличие документации о нём. Это поможет новым сотрудникам быстро адаптироваться, а уже бывалым не забывать, что происходит;
— разделение зон отвественности за каждый кусок кода между членами команды. Причем не так, чтобы Вася отвечал за А, а Коля за Б. Лучше чтобы и Вася, и Коля знали и А, и Б. Но кто-то из них был именно отвественным.
— наличие всевозможных инструментов для анализа кода: статические анализаторы, санитайзеры и т.д.
— наличие и мотивация опытных членов команды, которые могут много рассказать про решение;
— публичность наработок: когда ты делаешь что-то крутое, тебе обычно хочется поделиться об этом. Но что-то крутое не будет получаться сделать, если в вашем проекте будет плохое качество: вы будете тонуть в кусках кода, вместо развития продукта.


На CppConf 2021 я наткнулся на прекрасное видео от Анастасии Казаковой о том, какие инструменты есть для анализа С++ кода и как с этим вообще обстоят дела. Взгляните — не пожалеете ☺️. Но я всё же считаю, что весь этот тулинг — это лишь верхушка айсберга. И для обеспечения качества надо копать глубже 🤓.

Нейросети в мобилках

На дворе 2022, а мы еще даже понятия не имеем, как хорошо и классно запускать нейронные сети на мобильных девайсах 🤔. К сожалению, на текущий момент нет готового рецепта, как готовить нейронные сети под мобильные девайсы. Оптимизация и подготовка нейронных сетей под мобильные девайсы — одно из трендовых направлений в индустрии 🔼, потому что:

1. С одной стороны, хочется доставить пользователю удовольствие от того, как всё работает быстро, а еще и без интернета 😮;
2. С другой стороны, хочется поменьше тратить своего железа на пользователей — очень много из них ходят с девайсами, мощнее ноутбуков наших бабуль и дедуль, а железо компании денег стоит 😉.

Чтобы погрузиться в эту область, можно начать со всеобъемлющего гайда, который по поверхности проходится по существующим техникам. Но к сожалению, в реальной практике везде одни грабли и костыли 😔.

Например, возьмем хотя бы iOS и Android.

— На iOS полностью свои графические ускорители, а API так называемого Neural Engine, который так любят рекламировать в Apple, вообще скрыт. По факту, ты, как разработчик, просто сидишь и гадаешь, почему нейронка, которую ты запускаешь через их библиотеку, не хочет запускаться на нейронных движках, и запускается на обычной GPU, или вообще кидает EXEC_BAD_ADDRESS. 😡
— На Android просто тьма тьмущая устройств, всяких разных на вкус и цвет. Более того, одно и то же железо, но установленное разными вендорами телефонов, может показывать разные результаты🤪. На Android в большинстве случаев можно не ждать графических ускорителей (большая часть моих близких ходит с Android-телефонами и слабым железом) и прочих плюшек, как у Apple. Как и полагается, для Android написано куча софта для запуска нейронок, но никакой из них не решает задачу по всему зоопарку устройств так, чтобы это вызывало восторог 😔.

Как вы понимаете, уже только от зоопарка поддерживаемых девайсов можно немного встревожиться. А это я еще даже софтовые проблемы несовместимости не начал описывать. Также нужно подумать:
— На чем же запускать нейронку на конкретном девайсе (CPU, GPU, Neural Engine, etc)? А если троттлинг? А если места нет?
— Блин, а чего там по точности? Скорости? Памяти? Поеданию батареи?
— Чорт, а самая лучшая у нас нейронка очень большая, как её ужимать, чтобы сохранить качество?
— Господи, а самая лучшая у нас нейронка очень медленная, как её ускорять?
— ...

И нужно задачу запуска нейронной решить хотя бы на уровне кластера пользователей (по типу железа), а если можно на уровне отдельного пользователя — это вообще красота (но пока мне кажется, это нереально) ⛔️.

Мне кажется, что именно из-за огромного числа факторов и типов железа, мало кто делает запуск нейронных сетей на устройствах. Все отправляют запросы в сеть и получают ответ обратно. Все AI приложения на вашем телефоне обычно сделаны вендором этого телефона, который потратил много денег только на свой девайс, чтобы сделать классное решение (например, почти у всех свои умные камеры, режимы съемки и прочее).

В следующих постах я постараюсь описать то, каким образом можно решать некоторые из вопросов выше. В целом, это нереально интересная область!

endbr64 🤔

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

Запустим godbolt с опцией -O2 на следующем примере:

int main() {
return 0;
}

Он нам вернёт примерно следующее:

main:
xor eax, eax
ret

Теперь добавить опцию -fcf-protection и получим уже следующее:

main:
endbr64
xor eax, eax
ret

Что происходит? Остановите землю!!! 😮

Как известно, функция main в C++ — это входная точка запуска приложения в операционной системе. Но до вызова этой функции происходит еще множество вещей под капотом, по типу чтения бинаря, инициализации ресурсов и т.д. Затем некоторая функция __libc_start_main всё же вызывает main 🤓.

Но вот допустим, что у нас где-то появилось вредоносное ПО. Ну и по каким-то причинам ему нужно в runtime быстренько подменить функцию main (пока она еще не вызвалась из __libc_start_main), на другую, которая также находится в нашем бинарнике 😡. Хорошо, ПО нашло в памяти кусок, подменило адрес функции main, вызывается другая функция и происходит... завершение программы. Почему?

Потому что у нас есть инструкция endbr64 😇. И когда мы вызывали другую функцию, там не было endbr64 — процессор понял, что что-то не так, кинул клич и произошло экстренное завершение программы. Эта инструкция является некоторым сигналом о том, что вызов произошел успешно и можно двигаться дальше 🔼.

Насколько я знаю, эта инструкция есть у семейства процессоров Intel в рамках технологии CET, которая позволяет избегать некоторые атаки на приложения. Но она не панацея: если бы у той функции была эта инструкция, могло бы произойти ужасное 🥺!

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

Подробнее прочитать про то, как же всё-таки запускается приложения на C++ можно здесь.
Интересное объяснение, зачем нужна инструкция endbr64 — здесь.

Процессоры и их кэш 😐

В школе, когда мне рассказывали про кэш процессора я задавался вопросом: "А почему бы не сделать кэш процесса в кучу гигабайт?" Ну на самом деле, была бы жизнь слаще и веселее. Обычно ответ на этот вопрос: "Дорого". А что такое дорого?

Давай посмотрим на схему процессора, где расположены кэши процессора 🤓. L1 кэш максимально близко к ядрам. L2 — подальше, но при этом побольше. L3 — вообще далеко и супербольшой. И это не просто так.

Дело в том, что:
1. Нам нужно проводить сигнал как можно скорее. Сам электрический ток. Через все логические элементы.
2. Нам нужно делать дополнительные проверки: чтобы быть безопаснее, чтобы поменьше было ошибок от случайных битов.

Таким образом, чтобы гарантировать время работы кэша, сигнал должен проходить супербыстро в случае L1, чуть медленнее L2 и вообще медленно (в относительных единицах) — L3. Например, по информации здесь, доступ к кэшам работает за:
L1 — 0.5 ns
L2 — 2.8 ns
L3 — 12.9 ns

И собственно, в данном случае, "дорого" — это разработка. Придумать такую схему, чтобы L1 был на несколько гигабайт и доступ до него был бы примерно 0.5 ns по всей области покрытия — это было бы очень круто. Но пока, наверное, не получается. Но интересно, получится ли? 🤔

Восставший из мертвых

Мне иногда нравится поведение приложений, которые написаны на C++. И тут нравится скорее всего == “о, еще одно место, где можно прострелить ногу”.😂

Вспомним классику. В C++ мы можем создавать объекты через оператор new:

A *a = new A(); // Здесь A — это какой-то класс, неважно какой

После того, как мы закончили пользоваться этим объектам, правила хорошего тона гласят — уберись за собой:

delete a; // Уничтожение объекта

На самом деле за операторами new и delete стоит множество магии: аллокация памяти, создание/удаление объекта 🤪. Но не об этом сейчас.

Сделаем простой класс:

class A {
public:
void fun() {
++x;
std::cout << x << '\n'; // Просто выводим результат
};

private:
int x = 3;
};

Этот класс хранит в себе переменную со стандартным значением 3. При вызове функции fun, значение в переменной увеличивается на единичку, а потом полученной значение выводится в командную строку.

Теперь давайте создадим объект и вызовем у него fun:

A *a = new A();
a->fun(); // выведется 4

Никаких проблем. Теперь создадим ссылку на этот объект (ссылка по сути аналог ярлыка):

A& b = *a;

Удалим объект и вызовем fun у b:

delete a;
b.fun(); // может быть вывод каким угодно, но у меня 1

Тут давайте остановимся. Ссылка она ж ярлык. Мы когда файл удаляем — у нас ярлык становится невалидным. А тут почему-то работает. Что за магия 😳?

А теперь создадим еще один объект и снова вызовем fun у b:

A *c = new A();
b.fun(); // может быть вывод каким угодно, но у меня 4

Во-первых, почему b всё еще работает? Во-вторых, как мы перескочили с 1 до 4 😑?

На самом деле тут произошла вот какая магия:

1. Мы создали реальный объект в памяти;
2. Затем сказали программе — смотри, вот тебе ссылка на область памяти, там 100% лежит объект типа A;
3. Удалили объект, но программа всё еще думает, что по ссылке лежит реальный объект, и при этом знает, какую функцию вызвать — поэтому вызывает её, при этом она сама работает на невалидном участке памяти;
4. Потом снова создали объект — но времени так мало прошло, что программа просто в целях оптимизации положила объект в то же место, что и старый объект;
5. Теперь ссылка по сути указывает на область памяти, где реально лежит объект типа А, поэтому срабатывает валидный вызов функции.

Но на самом деле всё это — undefined behavior (UB) 🤓. Т.е. поведение, которое никак не определено стандартом и то, что у меня так получилось — мне повезло. UB — очень тяжело отлавливаются и являются сложными багами в коде 🥹.

Под конец вопросик на сообразительность. Мы тут с вами обсуждали классы с виртуальными методами. Так вот если в класс А добавить виртуальный метод — то программа вылетит с ошибкой. Почему?

UPD: А ошибочки не будет — всё же происходит UB. Подробности в комментариях.

Small talks

У нас в Яндексе куча мероприятий, чтобы понимать что где как и зачем происходит ☺️. Естественно, что большая часть из них — это NDA. Мне они очень сильно нравятся, потому что я всегда хочу всё знать 🙂 Я надеюсь, что когда-нибудь и я выйду и расскажу всему Яндексу, что мы крутого сделали в команде! Но даже после них создается какое-то ощущение, что не хватает личных историй 😔.

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

Так вот на днях я познакомился с проджектом проекта из внутренней инфраструктуры Яндекса. И мало того, что мы обменялись текущими настроениями, я еще узнал о полезном инструменте, который ранее не знал, что вообще ВАУ 😍.

И так постоянно: кто-то делает проекты в web3 , кто-то оптимизировал в кучу раз продакшн и т.д. И вот тогда ты понимаешь: вокруг тебя мир всё-таки развивается 😇!

Друзья, small talks — наше всё!

Ох мои бенчмарки (Часть 1)😔

Сейчас на работе я занимаюсь оптимизацией нейронных сеток для мобилок 🔼. Оптимизация под них подразумевает под собой замеры:
— По метрикам качества;
— По скорости работы;
— По кушанию батарейки;
— По кушанию оперативки.

В большинстве случаев с первым пунктом проблем нет: написал скрипты для прогона, посчитал по результатам метрики, сделал выводы. С третьим и четвертым достаточно инструментов от вендоров: на android это профилировщик Android Studio, на iOS — профилировщик Xcode. А вот со вторым проблема. Много проблем. 😮

🤔 Первое: под девайс надо собрать бенчмарк. Это, казалось бы простое дельце, только кажется таким. Приходится убивать много времени для того, чтобы совместить все версии библиотек на всех девайсах.

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

🤔 Третье: троттлинг (механизм защиты процессора от перегрева путем занижения производительности). Если запустить наши нейронки на среднестатистическом ПК на CPU — я уверяю вас, они будут летать и вы даже этого не заметите. Но на телефонах всё не так просто. Там другие процессоры и компоненты, они больше подвержены перегреву. А для бенчмарков важно иметь +- стабильную производительность. Я уже не говорю о том, что чиселки должны из раза в раз повторяться по одному и тому же тесту.

🤔 Четвертое: тестов ОЧЕНЬ много. Больше 500 на один девайс. Нужно думать о том, как их провести и как потом интерпретировать. 500 чиселок очень сложно просматривать (поверьте мне). Более того, сами по себе тесты разные и некоторые между собой (внутри одного девайса) не сравнимы. Например, есть замеры на CPU, GPU, NPU и т.д.

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

Первая проблема решается вручную. По второй проблеме я надеюсь доказать, что замена всё же необходима.👨‍💻 А по всем остальным проблемам решение я расскажу в следующем посте.☺️

Ох мои бенчмарки (Часть 2)😔

Как вы могли догадаться из предыдущего поста — вручную запускать я это собираюсь 😂. У меня несколько девайсов, на каждом более 600 тестов (да-да, за выходные еще добавилось). И кажется не для того меня нанимали, чтобы я такими вещами занимался. Конечно, нужно как-то автоматизировать 💃.

Замечу сразу — я писал обёртку для запуска готового инструмента из либы. И это по нескольким причинам:
🤔Только авторы либы обладают полным пониманием, как она работает, и способны написать тесты, которые учитывают много нюансов работы;
🤔 Даже если бы я собрался писать — это месяц, а то и больше времени работы, что естественно бессмысленно при наличии готового инструмента;
🤔 Многопоточные CPU приложения замерять сложно, GPU приложения замерять многократно сложнее;
🤔 Готовые инструменты как правило представляют подробную статистику что и как исполнялось, а не только общее число выдаёт — это очень полезно;
🤔 Если у либы нет такого инструмента, то возникает большой вопрос об эффективности этой библиотеки.

Утилита, которую я использую имеет множество параметров и определенное подмножество — это один эксперимент. Естественно, мне не нужны все подмножества данного множества: только определенные эксперименты были выбраны вручную 💪. Каждый эксперимент должен исполняться для каждой модели и для каждого окружения.

В целом подстановку всех этих параметров можно сделать путем написания нескольких вложенных циклов (хотя на деле лучше использовать hydra, что я и сделал), но есть проблема — если упадет, то придется начинать всё сначала 😮. На помощь приходить генерация плана тестов.

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

Маленькая ремарка: отслеживание прерывания тестов можно было бы как-то автоматически отслеживать, но в этом нет смысла: если что-то упало, то надо смотреть вручную, мб там телефон сгорел или перегрелся 🤪.

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

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

На деле оказалось куда проще, чем казалось 😃

Оптимизация работы диска

Linux — это очень сложная штука. Я уверен, что среднестатестический пользователь тратит просто уйму потенциала железа впустую, просто потому что он даже понятия не имеет, как настраивать систему оптимально под его железо. Но это и не нужно, только если вы не занимаетесь этим профессионально 👨‍💻.

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

Но что если мы сохранили наши данные где-то на жестких дисках в датацентрах, а сейчас нам нужна максимальная производительность 🤔? Мы можем пожертвовать ошибками и восстановлением, потому что данные просто можно будет еще раз скопировать (это просто дёшево). Например, если в /etc/fstab добавить noatime к параметрам монтирования диска, то как раз OS перестанет журналировать время последнего обращения к файлу. Это снизит немного нагрузку на диск, потому что раньше обращения к файлу нужно было синхронизировать и журналировать 😔.

Здесь пишут, что это в современных версиях уже не даёт существенного ускорения. Но если вы работаете с HDD, то точно должно докидывать (пару лет назад так было у меня, когда я читал сотни тысяч картинок для обучения).

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

Почему нейронные сети могут долго исполняться на мобильных устройствах?

На днях прочитал статью "An Improved One millisecond Mobile Backbone" от ребят из Apple об их взгляде на быстрые сетки для мобильных устройств. В ней рассматривается архитектура нейронной сети, которая по заверениям, работает очень быстро и относительно очень точно. Сама сеть является основой для множества задач компьютерного зрения: классификации, сегментации, поиск объектов и т.д.

Авторы выделяют две основные проблемы в нейронных сетях из-за которых последние работаю очень долго:

🤔 Используются дорогие функции активации
Любое действие стоит процессорного времени и вычисление сигмоиды стоит дороже взятия максимума, как это делается в ReLU 😃.

🤔 Слишком много ветвлений
В настоящий момент в нейронных сетях часто используется операция свертка, которую здорово научились исполнять параллельно (особенно для специфичных сверточных слоёв). Но чтобы features быстро не беднели 😁, обычно ставят skip-connections, которые идут параллельно основному потоку информации. Это приводит к тому, что во время исполнения нейронной сети необходимо ставить сихнронизации на точки соединения. Синхронизация — дорого 😔, поэтому и долго.

Если с первой проблемой побороться можно: придумать хитрую быструю функцию активации или как-то модифицировать ReLU, то со второй проблемой не понятно чего делать. Дело в том, что skip-connections нам нужны, чтобы нейронные сети делать действительно глубокими, а features богатыми и представляющими что-то из себя 🥺.

Авторы решают последнюю проблему следующим образом: во время обучения они используют skip-connections, а для инференса делают репараметризацию нейронной сети таким образом, чтобы этих skip-connections не было (подробнее лучше узнать в статье). Таким образом, у них получается линейная структура сети, которая практически не имеет точек синхронизации 🔼.

В статье есть таблички, где показывается скорость и точность полученной сети и сравнение с аналогами. При одинаковом числе параметров, сеть действительно работает быстрее (по крайней мере в статье) и точнее 🔼.

Что мне не понравилось в статье:
🤔 Использовали только iPhone 12 для экспериментов на мобилках
Думаю, можно было взять и побольше линейку iPhone.

🤔 Замеряли скорость на CPU на серверном процессоре – Intel Xeon Gold 5118
Это действительно было необходимо в статья про мобильные нейронные сети?

🤔 Есть замеры только на нейронных графических ускорителях
Это, конечно, хорошо, но я мб хочу запускать сеть на CPU, а результатов нет.

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

В целом, как по мне, статья годная. Как руки дотянутся, попробую их сеть у себя ☺️.