В гугле работают десятки команд (если не сотни конечно), причём многие параллельно над одними и теми же задачами. Конечно же, совершенно точно, что многие из них работают над перспективными направлениями, без ожидания вот прямо сейчас коммерческой отдачи. Многие вещи делают просто как proof of concept.
Согласен, внешне подчас так всё и выглядит. Мой вопрос был связан с тем, что из оценок Алексея можно сделать вывод, что представляемые отличительные особенности последних MobileNet и EfficientDet выглядят не просто спорно, а и чем-то близким к тупиковому пути развития, что, следуя этой мысли, могло быть очевидно ещё в процессе работы над моделями. У меня нет возможностей и наработок проверить на практике приведённые результаты, поэтому было интересно узнать, чем, согласно этому мнению, вообще руководствовались авторы. Думаю, мы все видели и очень высокие оценки, к примеру, EfficientDet, многие взялись за реализацию и применение, но было бы неудивительно, если бы это оказалось лишь следствием популярности, мощи и авторитета Google в этой области, да и разговоры о правдивости результатов в публикациях в целом по-прежнему идут, поэтому и с критическими отзывами полезно подробно ознакомиться.
И, я готов поспорить, что с высоты гугла yolo (особенно с учётом того, как её исторически трудно было тренировать, и из-за использования, скажем так, специфического и редкого фреймворка даркнет) — это просто одна из редких сеточек для детекции, которой кто-то где-то далеко наверное пользуется, но которая не стоит усилий, чтобы с ней детально сравниваться.
Я имею очень мало опыта работы с YOLO, и, честно говоря, не испытываю к ней особенного интереса, но мне она вовсе не кажется каким-то малозаметным изобретением, не говоря уже о том, что, если я не ошибаюсь, современная история однотактных моделей локализации объектов, фактически, с неё и началась. Но в сути Вы, наверное, правы: мы видим только результаты, которые было решено раскрыть для широкой общественности, а цели, которые перед собой ставят команды таких больших и авторитетных компаний могут быть совершенно различными.
4. На GPU (и Jetson) ещё больше проблем с Grouped/Depthwise-conv используемых в EfficientDet.
— MobileNetv3-small — 16.1% AP arxiv.org/pdf/1905.02244v5.pdf
— YOLOv4-416 — 41.2% AP и 30 FPS на Jetson Xavier AGX если запустить на OpenCV или tkDNN-TesnorRT batch=1
Результаты на AGX Xavier, полагаю, для int8? В любом случае, конечно, впечатляюще.
Тем не менее, мой опыт экспериментов на Jetson Nano даёт несколько иные результаты: модель на основе Tiny-YOLOv3 (416x416, fp16) смогла заработать в DeepStream 4.04 с частотой 32-33 кадра в секунду, на основе MobileNetv3-small+SSDLite (300x300, fp16) — 63-64 кадра в секунду при схожем уровне производительности. Не берусь рассуждать, насколько это отражает объективную картину, да и подтвердить заявление о производительности моделей мне нечем, набор данных рабочий, закрытый, а вот сравнение быстродействия доступно: пример с YOLO находится в комплекте с DeepStream 4, а реализацию на базе MobileNet я использовал эту.
Потому что тестируют с batch=64
Очень любопытно, спасибо, что уточнили! Я, увидев FPS, сразу неявно предположил, что действительно с batch-size=1 указано, а так это, конечно, меняет дело.
Если YOLOv4 запустить хотя бы с batch=4, то мы уже получаем более 400 FPS на той же RTX 2080Ti, с гораздо большей точностью чем у D0
Ну, в варианте выше, как я понимаю, mixed precision использовался, быстродействие в нём мне не известно, но всё-таки с fp16, наверное, напрямую трудно сравнивать. Хотя Вы правы, разница тут, в общем, очевидна.
— MobileNetv3 — оптимальна только для CPU / мобильных-CPU / устройств 5-летней давности
— YOLOv4 full/tiny — оптимальна для GPU и NPU/VPU/TPU
— EfficientDet — ни для чего не оптимальна
5. Google это коммерческая компания, с большими зарплатами, которые там не платят просто за написание статьи. Сказать что им не важна скорость — это сказать, что им не важны деньги.
Без всякого сарказма: у Вас есть объяснение тому, что при всём при этом разработки архитектур EfficientDet и MobileNetv3 вообще покинули стены лаборатории? Я в своих оценках могу основываться только на результатах, приведённых в статьях, которые, по Вашим словам, местами, мягко говоря, не без предвзятости (о чём, в общем, и в других источниках время от времени упоминается), хотя архитектурные решения EfficientDet мне кажутся элегантными. Неужели NIH-синдром? И считаете ли Вы базовую модель, EfficientNet, также не совсем удачной или с ней дела лучше?
Спасибо за уточнения и, пользуясь случаем, Ваш вклад в области компьютерного зрения и локализации объектов, Алексей!
Хотел бы добавить по некоторым пунктам:
4. Это действительно так, но, как можно судить, справедливо больше для исполнения моделей на Edge TPU и, можно ожидать, других специализированных аппаратных средствах для нейромоделей. Эта проблема также довольно подробно обсуждается авторами модели Pelee и в части, касающейся Edge TPU, статьи о MobileNetv3. Но, например, на оконечных устройствах NVIDIA семейства Jetson используются, фактически, традиционные видеоядра, и там зависимость быстродействия от количества операций более прямая. В моих собственных экспериментах на Jetson Nano вариант MobileNetv3-small показывает ещё несколько более впечатляющие результаты.
5. Как можно судить, в титульной реализации EfficientDet, похоже, вообще не очень-то преисполнялись темой быстродействия, поскольку вот автор одной из недавних реализаций на PyTorch заявляет о более высоком уровне в его экспериментах. Это, конечно, не официальные результаты и не объективные измерения, но автор достаточно авторитетен своими реализациями моделей на PyTorch, поэтому некоторое дополнительное представление его результаты, тем не менее, дать могут.
По опыту своих недавних экспериментов с похожим примером склонен с Вами согласиться. В общем случае, если мы не говорим о хранении в выделенном буфере значений только тривиально копируемых типов, выигрыш при выделении памяти, как это ни странно, с запасом компенсируется потерями на обслуживание нетривиально копируемых значений вместо дешёвых манипуляций с указателем. По моим наблюдениям, наибольшую проблему составляет потеря дешевизны сдвигающих конструктора и присваивания, да и swap превращается в довольно громоздкую операцию (частично этот вопрос поднимается Скотом Мейерсом здесь: std::string, SSO, and Move Semantics).
Чтобы не быть голословным и проиллюстрировать выводы примером, с которым я экспериментировал, приведу ссылку на код, благо он открыт. Здесь в ветке master реализовано type erasure-хранение в динамической памяти, а в compact_storage — во внутреннем буфере с использованием std::aligned_storage. Эквивалентный тест в этом файле (собирается при сборке проекта). Производительность и профили можете сравнить в своих условиях, на моей машине (GCC 4.8.2, GNU/Linux, x86_64) версия с внутренним хранением несколько менее производительна как в отладочной, так и в оптимизированной сборках.
Использую собранный когда-то по (B)LFS дистрибутив уже восьмой год в качестве повседневной ОС дома. Кроме замены цепочки компиляции, что тоже проделывал раза два-три, но и правда довольно трудоёмко, каких-то особенных проблем не чувствую и уж слишком много времени вроде бы не трачу. Конечно, в дистрибутивах с пакетным менеджером действий и времени требуется много меньше, но зато здесь есть преимущество, когда часто что-то правишь или экспериментируешь с кодом программ — не нужно «ломать» систему, т.к. контролируешь всё сам.
Начинал собирать действительно, во многом, с «копипасты», переходя с Windows, но в процессе узнал много нового, приобрёл новые интересы, и постепенно процесс стал более осмысленным. Вообще, сам для себя считаю книги LFS в изучении GNU/Linux очень полезными, считаю, что они мне очень помогли и в профессии сложиться. И да, если хочется узнать, как всё работает, это и на самом деле очень интересно :)
Признаюсь, несколько лет был, что называется, очарован этим набором библиотек, применял его и в своих личных, и в рабочих проектах, старался при любой имеющейся возможности предпочитать GStreamer пересекающимся по предметной области ffmpeg/libav. Привлекает и красивая концепция конвейера, и модульная архитектура, и с виду грамотное разделение API на уровни, когда для клиентского использования нет необходимости залезать во внутренности. Но, к сожалению, реализация сильно подкачала. Тут и огромное количество ошибок и «белых пятен» в элементах, и противоречивость некоторых частей API, и тёмные стороны в тонкостях работы конвейера. Фактически, начав писать какой-нибудь простенький плеер ты в определённый момент осознаёшь себя отлаживающим глубокие внутренности какого-нибудь элемента, который вроде бы должен был просто работать.
Разработчиков винить трудно, судя по опыту взаимодействия и их выступлениям, это действительно высококлассные специалисты. Проблема, наверное, в выборе языка C для продукта такого уровня сложности при ограниченном количестве активных разработчиков. Красноречиво об этом свидетельствует, например, функция set_name для GstObject, сама занимающая около 40 строк, вызывающая в них другую, «рабочую» функцию ещё на 50 строк, при этом они несколько раз захватывают и отпускают мьютексы не самым очевидным на свете образом и делают другие интересные вещи. В общем, чаще всего ситуация выглядит как «должно работать, но не работает». Так что в последнее время я хоть и по-прежнему люблю GStreamer, но уже с осторожностью.
В любом случае, спасибо автору за статью и интерес к этому мультимедийному фреймворку.
Вообще упоминались в дискуссии и inline-функции автора, в форме IsNumber, о выборе между функциями такой сигнатурой и шаблонной функцией мне и хотелось сказать.
Поддерживаю мысль по поводу шаблона. В одной из задач столкнулся с подобной дилеммой и после обдумывания тоже пришёл к выводу, что параметр, хоть и шаблонный, даёт больше гибкости, чем часть названия функции. А IsNumber() без шаблонных альтернатив может потом кого-нибудь и на макросы типа Is##type() спровоцировать.
Загорелся такой же идеей во время своего предыдущего апдрейда (конец 2007-го). Мне нужно было много процессорной мощности для программных синтезаторов и прочего ПО для создания музыки. В итоге всё получилось, собрал систему на двух Xeon'ах, но для себя сделал вывод, что больше так не буду :) В моём случае возникло достаточно много проблем даже помимо стоимости: начиная от меньшего выбора остальных компонентов вроде материнских плат и памяти, худшей совместимости с железом «пользовательского» сегмента (например, глухие подвисания с некоторыми моделями видеокарт, проблемы совместимости PCI-X и некоторых PCI-плат, необходимость в EATX-корпусе) и заканчивая общей направленностью всего этого железа для применения в серверах, а не где-то в жилых помещениях в качестве рабочего ПК (несколькоминутное тестирование вентиляторов с полным их разгоном при каждой перезагрузке, большое общее время загрузки).
В общем, надеюсь, что сейчас с этим много лучше, но свой следующий апгрейд буду всё-таки делать из настольных комплектующих. Серверные, конечно, хороши, но нужно хорошо понимать, с чем придётся иметь дело помимо более высокой стоимости.
Спасибо за уточнение.
Да, передача зависимостей в конструктор мне тоже нравится, при использовании обычно смущало только возрастающее количество параметров. Но я согласен с вашим замечанием в комментариях о том, что это дополнительный сигнал проверить, не перегружен ли класс функциональностью. А это скорее плюс.
3. Инжектить в поля — это моветон. Мешает использовать ваш объект без DI фреймворка, и делает зависимости класса менне явными (плюс много черной магии)
А как вместо этого лучше, в методы? Я просто для себя затрудняюсь решить этот вопрос, в своём коде чаще всего обращаюсь напрямую к фабричным методам, но мне понравилась идея автора об отражении зависимости в интерфейсе (пусть и закрытом) класса.
Я имею очень мало опыта работы с YOLO, и, честно говоря, не испытываю к ней особенного интереса, но мне она вовсе не кажется каким-то малозаметным изобретением, не говоря уже о том, что, если я не ошибаюсь, современная история однотактных моделей локализации объектов, фактически, с неё и началась. Но в сути Вы, наверное, правы: мы видим только результаты, которые было решено раскрыть для широкой общественности, а цели, которые перед собой ставят команды таких больших и авторитетных компаний могут быть совершенно различными.
Тем не менее, мой опыт экспериментов на Jetson Nano даёт несколько иные результаты: модель на основе Tiny-YOLOv3 (416x416, fp16) смогла заработать в DeepStream 4.04 с частотой 32-33 кадра в секунду, на основе MobileNetv3-small+SSDLite (300x300, fp16) — 63-64 кадра в секунду при схожем уровне производительности. Не берусь рассуждать, насколько это отражает объективную картину, да и подтвердить заявление о производительности моделей мне нечем, набор данных рабочий, закрытый, а вот сравнение быстродействия доступно: пример с YOLO находится в комплекте с DeepStream 4, а реализацию на базе MobileNet я использовал эту.
Очень любопытно, спасибо, что уточнили! Я, увидев FPS, сразу неявно предположил, что действительно с batch-size=1 указано, а так это, конечно, меняет дело.
Ну, в варианте выше, как я понимаю, mixed precision использовался, быстродействие в нём мне не известно, но всё-таки с fp16, наверное, напрямую трудно сравнивать. Хотя Вы правы, разница тут, в общем, очевидна.
Без всякого сарказма: у Вас есть объяснение тому, что при всём при этом разработки архитектур EfficientDet и MobileNetv3 вообще покинули стены лаборатории? Я в своих оценках могу основываться только на результатах, приведённых в статьях, которые, по Вашим словам, местами, мягко говоря, не без предвзятости (о чём, в общем, и в других источниках время от времени упоминается), хотя архитектурные решения EfficientDet мне кажутся элегантными. Неужели NIH-синдром? И считаете ли Вы базовую модель, EfficientNet, также не совсем удачной или с ней дела лучше?
Хотел бы добавить по некоторым пунктам:
4. Это действительно так, но, как можно судить, справедливо больше для исполнения моделей на Edge TPU и, можно ожидать, других специализированных аппаратных средствах для нейромоделей. Эта проблема также довольно подробно обсуждается авторами модели Pelee и в части, касающейся Edge TPU, статьи о MobileNetv3. Но, например, на оконечных устройствах NVIDIA семейства Jetson используются, фактически, традиционные видеоядра, и там зависимость быстродействия от количества операций более прямая. В моих собственных экспериментах на Jetson Nano вариант MobileNetv3-small показывает ещё несколько более впечатляющие результаты.
5. Как можно судить, в титульной реализации EfficientDet, похоже, вообще не очень-то преисполнялись темой быстродействия, поскольку вот автор одной из недавних реализаций на PyTorch заявляет о более высоком уровне в его экспериментах. Это, конечно, не официальные результаты и не объективные измерения, но автор достаточно авторитетен своими реализациями моделей на PyTorch, поэтому некоторое дополнительное представление его результаты, тем не менее, дать могут.
Успехов Вам в будущих разработках!
Чтобы не быть голословным и проиллюстрировать выводы примером, с которым я экспериментировал, приведу ссылку на код, благо он открыт. Здесь в ветке master реализовано type erasure-хранение в динамической памяти, а в compact_storage — во внутреннем буфере с использованием std::aligned_storage. Эквивалентный тест в этом файле (собирается при сборке проекта). Производительность и профили можете сравнить в своих условиях, на моей машине (GCC 4.8.2, GNU/Linux, x86_64) версия с внутренним хранением несколько менее производительна как в отладочной, так и в оптимизированной сборках.
Начинал собирать действительно, во многом, с «копипасты», переходя с Windows, но в процессе узнал много нового, приобрёл новые интересы, и постепенно процесс стал более осмысленным. Вообще, сам для себя считаю книги LFS в изучении GNU/Linux очень полезными, считаю, что они мне очень помогли и в профессии сложиться. И да, если хочется узнать, как всё работает, это и на самом деле очень интересно :)
Разработчиков винить трудно, судя по опыту взаимодействия и их выступлениям, это действительно высококлассные специалисты. Проблема, наверное, в выборе языка C для продукта такого уровня сложности при ограниченном количестве активных разработчиков. Красноречиво об этом свидетельствует, например, функция set_name для GstObject, сама занимающая около 40 строк, вызывающая в них другую, «рабочую» функцию ещё на 50 строк, при этом они несколько раз захватывают и отпускают мьютексы не самым очевидным на свете образом и делают другие интересные вещи. В общем, чаще всего ситуация выглядит как «должно работать, но не работает». Так что в последнее время я хоть и по-прежнему люблю GStreamer, но уже с осторожностью.
В любом случае, спасибо автору за статью и интерес к этому мультимедийному фреймворку.
В общем, надеюсь, что сейчас с этим много лучше, но свой следующий апгрейд буду всё-таки делать из настольных комплектующих. Серверные, конечно, хороши, но нужно хорошо понимать, с чем придётся иметь дело помимо более высокой стоимости.
Да, передача зависимостей в конструктор мне тоже нравится, при использовании обычно смущало только возрастающее количество параметров. Но я согласен с вашим замечанием в комментариях о том, что это дополнительный сигнал проверить, не перегружен ли класс функциональностью. А это скорее плюс.
А как вместо этого лучше, в методы? Я просто для себя затрудняюсь решить этот вопрос, в своём коде чаще всего обращаюсь напрямую к фабричным методам, но мне понравилась идея автора об отражении зависимости в интерфейсе (пусть и закрытом) класса.