3. Я запускал YOLOv4 256x256 async=3 (Leaky вместо Mish) на 1 Watt neurochip Intel Myriad X со скоростью 11 FPS. При этом точность на MSCOCO test-dev такая же как у обычного YOLOv3:
YOLOv4 256x256 (leaky) — 33.3% AP — 53.0% AP50
YOLOv3 416x416 (default) — 31.0% AP — 55.3% AP50.
Можно такую умную камеру+нейрочип использовать shop.luxonis.com — одновременно и объекты обнаруживает и расстояние до них
Потому что мы сравниваем данные опубликованные в статьях авторов этих нейронных сетей, за которые они ручаются и вряд ли они занижают свои результаты и достижения. И потому что авторы CetnerMask опубликовали свои результаты только на GPU Pascal и только AP (без AP50).
Все фичи которые применяются при определении точности (ensembles, multiscale/flip, high resolution, ...), должны применяться и при определении скорости.
В отличие от большинства других статей, мы публикуем наши результаты на нескольких архитектурах GPU: Maxwell/Pascal/Volta. И сравниваем точность/скорость только на одинаковых архитектурах.
А не как авторы статей CenterNet, EfficientDet,… запускают свои сети на быстрых GPU, а чужие на старых медленных GPU )
Авторы статьи CenterNet сравнили свой CenterNet на GPU-Pascal с производительность 11 TFlops с Yolov3 на старой GPU-Maxwell с производительностью 6 TFlops.
6.1. Object detection Table 1 shows our results on COCO validation with different backbones and testing options, while Figure 1 compares CenterNet with other real-time detectors. The running time is tested on our local machine, with Intel Core i7-8086K CPU, Titan Xp GPU, Pytorch 0.4.1, CUDA 9.0, and CUDNN 7.1
А если сравнить честно на одной и той же GPU, то:
CenterNet-DLA (SS + Flip) — 28 FPS (TitanXP) — 39.2% AP — 57.1% AP50
Darknet YOLOv3 608x608 — ~34 FPS (TitanXP) — 33.0% AP — 57.9% AP50
Авторы EfficientDet из Google Brain пошли ещё дальше, они использовали GPU Volta с Tensor Cores — запустили EfficientDet на GPU не на 1, а на 2 поколения выше, чем Yolov3 :) Но они хотя бы формально поступили чуть более честно – к своему неверному сравнению сделали сноску (что сравнение не верно) – которую увидят только те, кто разбираются: arxiv.org/pdf/1911.09070v4.pdf
Как выглядит честное сравнение Yolov3 и EfficientDet на одинаковом GPU вы видите на наших графиках.
И это им приходится мухлевать, чтобы победить старую YOLOv3, не говоря уже о новой YOLOv4, которая значительно точнее/быстрее.
Чего уж там говорить о горе любителях сравнения из интернета, которые точность проверяют на одном фреймворке с высоким разрешением с multiscale/flip inference-time-data-augmentation и на val5k-датасете, а скорость проверяют на другом фреймворке с низким разрешением без multiscale/flip да ещё с квантованием int8. И сравнивают с другими моделями на test-dev датасете да ещё так же на разных GPU. Вообщем все что только можно смешают и перепутают.
PS
YOLOv4 создавалась при поддержке Academia Sinica и MoST (Ministry of Science and Technology) Taiwan в рамках проекта, целью которого изначально было не создать, а выбрать лучшую нейронную сеть по заказу коммерческих корпораций. Поэтому они достаточно тщательно проверяли наши результаты. Собственно Tsung-Yi Lin автор MSCOCO, RetinaNet, FPN,… выходец из Academia Sinica тоже в курсе этих разработок, как и многие другие значимые люди.
Если делать Transfer-learning / Fine-tuning без заморозки weights/BN, то точность на 0.5 — 1.5 AP ниже с малым mini-batch, чем с большим, т.к. статистика mean/variance будет вычислена заново с малым mini-batch.
Если заморозить большую часть weights и BN-statistic, то проблем с маленьким mini-batch почти нет, но это подходит только если контекст и объекты обучающего датасета сильно совпадают с pre-trained weights, т.к. в этом случае большая (замороженная) часть сети не обучается. Если контекст/объекты сильно отличаются, то точность может упасть на 10 — 20 AP.
Это справедливо для больших корректных датасетов: Microsoft COCO, Google OpenImages, Stanford ImageNet, Berkeley BDD100k, Toyota Kitti… А на малых датасетах что угодно может быть.
Точнее CenterNet-DLA (SS + Flip) тестировали на TitanXP (11.3 TFlops GP102-450-A1 Pascal 2017 год), а Yolo v3 на Titan X (6.6 TFlops GM200-400 Maxwell 2015 год).
Так что всего на 1 поколение
Table 1 shows our results on COCO validation with different backbones and testing options, while Figure 1 compares CenterNet with other real-time detectors. The running time is tested on our local machine, with Intel Core
i7-8086K CPU, Titan Xp GPU, Pytorch 0.4.1, CUDA 9.0,
and CUDNN 7.1. We download code and pre-trained models12
to test run time for each model on the same machine.
1. Они тестировали CenterNet-DLA на GPU TitanV (GV100-400-A1 Volta 2017 год), а для Yolo v3 взяли значение из статьи 20 FPS на GPU TitanX (GM200-400 Maxwell 2015 год), конечно если взять видеокарту на 2 поколения новее, то скорость будет больше ) А если запускать на одной и той же GPU, то Yolo v3 в 3 раза быстрее, чем CenterNet-DLA (SS + Flip).
2. Yolo v3 608x608 точнее по AP50 и быстрее в 3 раза чем CenterNet-DLA (SS + Flip)
3. Они для CenterNet-DLA (SS + Flip) — используют test time data augmetation = flip, т.е. делают несколько inference для одной картинки вместо одного, иначе точность будет ниже
4. Ну и попробуйте сами потестить совершенно разные модели одновременно и по FPS в реальных задачах и по AP на MSCOCO test-dev обязательно! на этой же сетке, очень сильно удивитесь )
плюс они в статье репортят SOTA-скорость у CenterNet-DLA (в таблице 2) при AP выше, чем у YOLOv3, что в моих глазах выглядело как SOTA в speed/accuracy trade-off (что, на мой взгляд, для детекторов важнее, чем только speed или только AP).
Про какую статью идет речь, можно ссылку на статью и скриншот с CenterNet-DLA со скоростью FPS и точностью AP?
p.s. Поздравляю с YOLOv4! Выглядит очень многообещающе, однозначно добавлю в этот пост Вашу статью.
Привет, nVidia GPU поддерживаются как с CUDA без cuDNN, так и с CUDA + cuDNN?
А касаемо github.com/opencv/opencv/issues/15033 что сейчас реализовано из LSTM?
На кучу других алгоритмов мало обращают внимание может потому, что только нейронные сети дали огромный скачок точности в большинстве рейтингов, по сравнению с этой кучей: https://arxiv.org/pdf/1905.05055v2.pdf
Вот DPM не нейронка, а все остальные в топе — только нейронки. Т.е. дело не только в рекламной компании.
Как только в топ рейтингка попадет дргой алгоритм (не нейронка) — все переключатся на него.
1. GFLOPS и BFLOPS грубо говоря одно и тоже, только в GFLOPS измеряют производительность железа (CPU, GPU, ...), а в BFLOPS измеряю затраты алгоритма (нейронной сети).
2. Google и некоторые другие пишут значение BFLOPS в 2 раза меньше (они считают 2 (операции умножение и последующее сложение) за одну FMA-операцию, т.к. в их железе Google ASIC TPU v3 это выполнено как один конвейер). Т.е. когда Google пишет про свои нейронки MixNet/EfficientDet/EfficientNet, то он считает 2 операции за 1, и занижает BFLOPS в 2 раза, а когда Google пишет про своё железо TPU, то уже считает 2 операции за 2 :) Т.е. даже Google на официальном уровне манипулирует данными, то FMA это 1 операция, то это 2 операции.
В nVidia GPU или в сетях Yolo сколько операций есть — столько и пишется.
3. MixNet, EfficientNet, EfficientDet, MobileNetV3, GhostNet,… — имеют в ~20 раз меньше BFLOPS, чем другие модели с той же точностью, но при этом в ~2 раза медленнее их на GPU/TPUv3. Это из-за depthwise/groped-convolutional, которые выполняются крайне медленно на GPU/TPUv3. Поэтому даже Google в статьях публикует EfficientDet/Net с низкими BFLOPS (depthwise/groped-convolutional), а в продакшене использует сети без depthwise/groped-convolutional и без SE-блоков под названием EfficientNet-TPU-edge: ai.googleblog.com/2019/08/efficientnet-edgetpu-creating.html
Вычисления depthwise/groped-convolutional слоев очень плохо распараллеливаются, поэтому на 1-потоке CPU они работают быстро, на множестве потоков с SIMD работают не сильно ускоряются, а на GPU/TensorCores/TPU работают медленнее, чем обычные convolutional-слои.
Поэтому малое значение BFLOPS ещё не значит, что сеть будет быстрая.
4. Размер файла весов зависит от (размера_фильтра * количество_фильтров * колво_каналов / колво_групп), а BFLOPS зависит от ещё от размера_слоя. При этом колво_групп может снижать файл весов и BFLOPS, но увеличивать время выполнения. Поэтому размер файла весов, BFLOPS и FPS могут вообще не коррелировать.
5. CSP простая и хорошая идеяarxiv.org/abs/1911.11929v1 — делать Concatenate = (выходов после предыдущего subsampling) + (перед следующим subsampling). Применяется к любой модели, позволяет строить сети ещё глубже, чем с обычным Residual-connection и улучшает точность.
Пока что у акселераторов TFlops дутые (иногда более, чем в 100 раз).
Вполне возможно, что nVidia забронзовело, но ничего явно лучше, чем nVidia GPU до сих пор нет.
Формально nVidia GPU (Tensor_Cores_V100 = 125 TFlops) и Google TPUv3 (90 TFlops) имеют очень высокие TOPS и TOPS/watt.
И нейросеть Google EfficientNet B0 имеет крайне низкий BFLOPS (0.900 = 0.450 FMA) и высокий Top1 (71.3% batch=30 или 76.3% batch=2048).
Только когда запускаешь Google EfficientNet B0 (0.9 BFLOPS = 0.45 FMA) на nVidia GPU RTX 2070 (52 000 GFlops Tensor Cores), то получаем 143 FPS на бенчмарке (batch=1), т.е. как если бы GPU работал со скоростью 128 Gflops, что в 400 раз ниже, чем заявленные 52 000 Gflops. Тоже самое и с TPU, поэтому Google использует для TPU-edge модифицированные EfficientNet у которых BFLOPS гораздо выше, но и (парадокс) FPS тоже выше.
Т.е. для формальных рейтингов они использую одно, а в продакшене используют совсем другое.
Т.е. пока в значительной степени ускорение акселераторов (TPU, Tensor Cores, ...) дутое.
То ли Google нашел способ как кардинально ускорить DW-conv, SE-block,… в будущих TPU, то ли их показатели Top1/BFLOPS заводят их все дальше в тупик (EfficientNet, MixNet, MobileNetv3, GhostNet, ...), в то время пока nVidia ускорило BIT1-conv, но не спешит ускорять DW-conv.
И это ещё пол беды, у многих других SOTA-нейросетей результаты просто не воспроизводятся и отличаются от заявленных в 2 раза и более.
Но все таки такие штуки как Intel Myriad X, Google TPU Edge и их развитие радуют.
TPUv1 лучше, чем GPU (вероятно K80) в 28 раз по INT8-TOPS/Watt — сравнивает Google.
TPUv3 (90 TFLOPS16 / 200 Watt = 0.45) в 1.1x раза хуже, чем GPU V100 PCIe (125 TFLOPS16 / 250 Watt = 0.5) по TFlops/watt и в 1.38x раз хуже по абсолютному значению Tflops — сравнивает Huawei
Просто в первом случае:
сравнение Google vs nVidia делал Google, а не сторонняя фирма
сравнивал по INT8, потому что TPUv1 умело только INT8 вычисления, а GPU был на тот момент слабо заточен под INT8 (сейчас Tensor Cores поддерживает INT8 с 4х производительностью относительно TC-Float32)
на INT8 можно делать только Inference, но нельзя обучать с приемлемой точностью (модели INT8 и BIT1 всегда обучаются на FP32/16 и затем квантуются)
А во втором случае сравнение Google vs nVidia делала Huawei, которая сравнила не предвзято Google TPU и nVidia GPU, и предвзято выпятила свой Neurochip.
Поэтому может nVidia и забронзовело, но ничего явно лучше, чем nVidia GPU до сих пор нет.
И все очень зависит от акселераторов. У них рост точно будет, но если будет прорыв (в 100 раз быстрее GPU хотя бы в узких областях) — это будет мощнейший толчок. Основания для оптимизма есть.
Если акселераторы будут в 100 раз быстрее GPU, то их встроят в GPU (как встроили Tensor Cores), и они уже не будут быстрее GPU :)
А во сколько раз по FPS/Watt уже сейчас акселераторы быстрее, чем GPU?
И какие это акселераторы? Intel Myriad X, Google TPU, Huawei neurochip, ....
Есть ли какие-то акселераторы, которые значительно ускоряют depthwise-convolutional-layers, а именно модели EfficientNet (EfficientDet), MixNet, GhostNet, MobileNetv3? Потому как BFLOPS у них мало, а FPS на CPU и GPU ниже, чем у старых обычных ResNet при тех же Top1/Top5 accuracy.
И как считаете, какие оптимизации победят: depthwise-convolutional или binary-convolutional (xnor-net) или какие-то ещё?
Но 1. все таки есть падение точности ~2-4%, требуется обучение используя SVR и есть сложности по использованию новых фишек: mish, weighted-fusion (ASFF, BiFPN, ...),… 2. они сравнили Yolo_v2_float32 (а не bit1) на GPU против Yolo_v2_bit1 на FPGA 3. бинарные операции теперь доступны в Tensor Cores начиная с CC 7.5 — реализация GEMM_BINARY для Yolo-XnorNet на GPU используя Tensor Cores: github.com/AlexeyAB/darknet/blob/dcfeea30f195e0ca1210d580cac8b91b6beaf3f7/src/im2col_kernels.cu#L1224-L1419
Как я понял в PVS Studio начиная с версии 6.27 (2018 года) можно включить полноценную проверку на соответствие кода стандарту MISRA C и MISRA C++? https://www.viva64.com/ru/b/0596/
С одной стороны, мы делаем pruning только для весов, но не для input, т.е. вместо GEMM dense-dense, мы можем делать sparse-GEMM sparse-dense, а это в общем случае ещё медленнее, даже используя оптимизированную библиотеку cuSPARSE: github.com/tensorflow/tensorflow/issues/5193#issuecomment-350989310
С другой стороны, если мы берем частный случай — блочная разряженность с блоками от 8x8 до 32x32, то можно получить ускорение в ~7x раз на NVIDIA Titan X Pascal openai.com/blog/block-sparse-gpu-kernels
реализация для TensorFlow: github.com/openai/blocksparse
Но что будет с точностью на больших сетях, которые используются в продакшене и больших датасетах — большой вопрос.
Посмотрим когда nVidia реализует блочную разряженность в cuDNN оптимизированной под TensorCores.
Above this size, the winning tickets that we find learn faster than the original network and reach higher test accuracy.
Интересно то, что урезанные в 10 раз сети обучаются (сходятся) быстрее и имеют более высокую точность, чем изначально большие сети: https://openreview.net/pdf?id=rJl-b3RcF7
Интересно, что "выигрышные билеты выиграли в лотерее инициализации" и "начальные веса сделали обучение особенно эффективным", следовательно важно не расположение связи, а её инициализация?
The winning tickets we find have won the initialization lottery: their connections have initial weights that make training particularly effective.
На рисунках 9 и 10 показано, что сбрасывание весов (resetting) до начальных выигрышных весов даёт лучшую точность, чем продолжение до-обучения уже обученных выигрышных весов.
Т.е. из 3-х весов:
1. выигрышные, которые сделали обучение особенно эффективными
2. выигрышные, которые сделали обучение особенно эффективными, и обученные
3. совершенно случайные
Для урезанной архитектуры веса-1 получаются самыми лучшими.
1. Главная проблема — полученные разряженные сети не оптимизированы ни под фреймворки, ни под железо NPU/SIMD/TensorCores/… (что намного сложнее изменить). Т.е. прироста скорости не дают никакого.
2. Они делают pruning под конкретный датасет, соответственно, даже если уменьшенная в 20 раз сеть обучается с нуля до той же точности, то она это делает только на этом же датасете. А заранее ты никогда не знаешь на сколько новый датасет сложнее или легче предыдущего.
* Будет датасет сложнее — и точность сильно упадет (урезанная сеть не подходит)
* Будет датасет легче — и можно было бы обрезать весов намного больше (урезанная сеть ещё слишком большая)
3. Они не тестировали на датасетах крупнее MNIST / Cifar.
4. На более глубоких сетях уже начинаются проблемы без warmup.
We only consider vision-centric classification tasks on smaller datasets (MNIST, CIFAR10). We do not investigate larger datasets (namely Imagenet (Russakovsky et al., 2015))
Although we reduce parameter-counts, the resulting architectures are not optimized for modern libraries or hardware. In future work, we intend to study other pruning methods from the extensive contemporary literature, such as structured pruning (which would produce networks optimized for contemporary hardware) and non-magnitude pruning methods (which could produce smaller winning tickets or find them earlier).
On deeper networks (Resnet-18 and VGG-19), iterative pruning is unable to find winning tickets unless we train the networks with learning rate warmup. In future work, we plan to explore why warmup is necessary and whether other improvements to our scheme for identifying winning tickets could obviate the need for these hyperparameter modifications.
Интересно даже в чем причина — не было достаточного количества спецов по concurrency, или не нашли универсальную реализацию concurrent (queue, stack,...) для большинства случаев?
Сейчас Yolov3 нативно поддерживается в nVidia Deepstream 4.0 (TensorRT) поэтому никаких проблем вообще нет: news.developer.nvidia.com/deepstream-sdk-4-now-available
Мало того, Xnor.ai научились обучать Yolo на bit1 весах, собственно основатели и создали Yolo: www.forbes.com/sites/janakirammsv/2020/01/19/apple-acquires-xnorai-to-bolster-ai-at-the-edge/#7727a8913975
2. tkDNN относительно новая библиотека.
3. Я запускал YOLOv4 256x256 async=3 (Leaky вместо Mish) на 1 Watt neurochip Intel Myriad X со скоростью 11 FPS. При этом точность на MSCOCO test-dev такая же как у обычного YOLOv3:
YOLOv4 256x256 (leaky) — 33.3% AP — 53.0% AP50
YOLOv3 416x416 (default) — 31.0% AP — 55.3% AP50.
Можно такую умную камеру+нейрочип использовать shop.luxonis.com — одновременно и объекты обнаруживает и расстояние до них
YOLOv3-spp 192x320 на iPhone (A13 iOS) показывает более 30 FPS apps.apple.com/app/id1452689527
Все фичи которые применяются при определении точности (ensembles, multiscale/flip, high resolution, ...), должны применяться и при определении скорости.
В отличие от большинства других статей, мы публикуем наши результаты на нескольких архитектурах GPU: Maxwell/Pascal/Volta. И сравниваем точность/скорость только на одинаковых архитектурах.
А не как авторы статей CenterNet, EfficientDet,… запускают свои сети на быстрых GPU, а чужие на старых медленных GPU )
Авторы статьи CenterNet сравнили свой CenterNet на GPU-Pascal с производительность 11 TFlops с Yolov3 на старой GPU-Maxwell с производительностью 6 TFlops.
Screenshot CenterNet: arxiv.org/pdf/1904.07850.pdf
Screenshot Yolov3 (2018): arxiv.org/pdf/1804.02767v1.pdf
А если сравнить честно на одной и той же GPU, то:
CenterNet-DLA (SS + Flip) — 28 FPS (TitanXP) — 39.2% AP — 57.1% AP50
Darknet YOLOv3 608x608 — ~34 FPS (TitanXP) — 33.0% AP — 57.9% AP50
Авторы EfficientDet из Google Brain пошли ещё дальше, они использовали GPU Volta с Tensor Cores — запустили EfficientDet на GPU не на 1, а на 2 поколения выше, чем Yolov3 :) Но они хотя бы формально поступили чуть более честно – к своему неверному сравнению сделали сноску (что сравнение не верно) – которую увидят только те, кто разбираются: arxiv.org/pdf/1911.09070v4.pdf
Как выглядит честное сравнение Yolov3 и EfficientDet на одинаковом GPU вы видите на наших графиках.
И это им приходится мухлевать, чтобы победить старую YOLOv3, не говоря уже о новой YOLOv4, которая значительно точнее/быстрее.
Чего уж там говорить о горе любителях сравнения из интернета, которые точность проверяют на одном фреймворке с высоким разрешением с multiscale/flip inference-time-data-augmentation и на val5k-датасете, а скорость проверяют на другом фреймворке с низким разрешением без multiscale/flip да ещё с квантованием int8. И сравнивают с другими моделями на test-dev датасете да ещё так же на разных GPU. Вообщем все что только можно смешают и перепутают.
PS
YOLOv4 создавалась при поддержке Academia Sinica и MoST (Ministry of Science and Technology) Taiwan в рамках проекта, целью которого изначально было не создать, а выбрать лучшую нейронную сеть по заказу коммерческих корпораций. Поэтому они достаточно тщательно проверяли наши результаты. Собственно Tsung-Yi Lin автор MSCOCO, RetinaNet, FPN,… выходец из Academia Sinica тоже в курсе этих разработок, как и многие другие значимые люди.
Это справедливо для больших корректных датасетов: Microsoft COCO, Google OpenImages, Stanford ImageNet, Berkeley BDD100k, Toyota Kitti… А на малых датасетах что угодно может быть.
Для точности формулировок Transfer-learning vs Fine-tuning: github.com/AlexeyAB/darknet/issues/2139
Так что всего на 1 поколение
CenterNet-DLA (SS + Flip) — 28 FPS (TitanXP) — 39.2% AP — 57.1% AP50
Darknet YOLOv3 608x608 — ~34 FPS (TitanXP) — 33.0% AP — 57.9% AP50
CenterNet: arxiv.org/pdf/1904.07850.pdf
Yolo v3: arxiv.org/pdf/1804.02767v1.pdf
Yolo v3: pjreddie.com/darknet/hardware-guide
Darknet YOLOv3 608x608 — 73 FPS (TitanV) — 33.0% AP — 57.9% AP50
1. Они тестировали CenterNet-DLA на GPU TitanV (GV100-400-A1 Volta 2017 год), а для Yolo v3 взяли значение из статьи 20 FPS на GPU TitanX (GM200-400 Maxwell 2015 год), конечно если взять видеокарту на 2 поколения новее, то скорость будет больше ) А если запускать на одной и той же GPU, то Yolo v3 в 3 раза быстрее, чем CenterNet-DLA (SS + Flip).
2. Yolo v3 608x608 точнее по AP50 и быстрее в 3 раза чем CenterNet-DLA (SS + Flip)
3. Они для CenterNet-DLA (SS + Flip) — используют test time data augmetation = flip, т.е. делают несколько inference для одной картинки вместо одного, иначе точность будет ниже
4. Ну и попробуйте сами потестить совершенно разные модели одновременно и по FPS в реальных задачах и по AP на MSCOCO test-dev обязательно! на этой же сетке, очень сильно удивитесь )
Про какую статью идет речь, можно ссылку на статью и скриншот с CenterNet-DLA со скоростью FPS и точностью AP?
Спасибо!
А что конкретно натолкнуло на такие мысли, по каким показателям они SOTA?
А касаемо github.com/opencv/opencv/issues/15033 что сейчас реализовано из LSTM?
На кучу других алгоритмов мало обращают внимание может потому, что только нейронные сети дали огромный скачок точности в большинстве рейтингов, по сравнению с этой кучей: https://arxiv.org/pdf/1905.05055v2.pdf
Вот DPM не нейронка, а все остальные в топе — только нейронки. Т.е. дело не только в рекламной компании.
Как только в топ рейтингка попадет дргой алгоритм (не нейронка) — все переключатся на него.
2. Google и некоторые другие пишут значение BFLOPS в 2 раза меньше (они считают 2 (операции умножение и последующее сложение) за одну FMA-операцию, т.к. в их железе Google ASIC TPU v3 это выполнено как один конвейер). Т.е. когда Google пишет про свои нейронки MixNet/EfficientDet/EfficientNet, то он считает 2 операции за 1, и занижает BFLOPS в 2 раза, а когда Google пишет про своё железо TPU, то уже считает 2 операции за 2 :) Т.е. даже Google на официальном уровне манипулирует данными, то FMA это 1 операция, то это 2 операции.
В nVidia GPU или в сетях Yolo сколько операций есть — столько и пишется.
3. MixNet, EfficientNet, EfficientDet, MobileNetV3, GhostNet,… — имеют в ~20 раз меньше BFLOPS, чем другие модели с той же точностью, но при этом в ~2 раза медленнее их на GPU/TPUv3. Это из-за depthwise/groped-convolutional, которые выполняются крайне медленно на GPU/TPUv3. Поэтому даже Google в статьях публикует EfficientDet/Net с низкими BFLOPS (depthwise/groped-convolutional), а в продакшене использует сети без depthwise/groped-convolutional и без SE-блоков под названием EfficientNet-TPU-edge: ai.googleblog.com/2019/08/efficientnet-edgetpu-creating.html
Вычисления depthwise/groped-convolutional слоев очень плохо распараллеливаются, поэтому на 1-потоке CPU они работают быстро, на множестве потоков с SIMD работают не сильно ускоряются, а на GPU/TensorCores/TPU работают медленнее, чем обычные convolutional-слои.
Поэтому малое значение BFLOPS ещё не значит, что сеть будет быстрая.
4. Размер файла весов зависит от (размера_фильтра * количество_фильтров * колво_каналов / колво_групп), а BFLOPS зависит от ещё от размера_слоя. При этом колво_групп может снижать файл весов и BFLOPS, но увеличивать время выполнения. Поэтому размер файла весов, BFLOPS и FPS могут вообще не коррелировать.
5. CSP простая и хорошая идея arxiv.org/abs/1911.11929v1 — делать Concatenate = (выходов после предыдущего subsampling) + (перед следующим subsampling). Применяется к любой модели, позволяет строить сети ещё глубже, чем с обычным Residual-connection и улучшает точность.
Вполне возможно, что nVidia забронзовело, но ничего явно лучше, чем nVidia GPU до сих пор нет.
Формально nVidia GPU (Tensor_Cores_V100 = 125 TFlops) и Google TPUv3 (90 TFlops) имеют очень высокие TOPS и TOPS/watt.
И нейросеть Google EfficientNet B0 имеет крайне низкий BFLOPS (0.900 = 0.450 FMA) и высокий Top1 (71.3% batch=30 или 76.3% batch=2048).
Только когда запускаешь Google EfficientNet B0 (0.9 BFLOPS = 0.45 FMA) на nVidia GPU RTX 2070 (52 000 GFlops Tensor Cores), то получаем 143 FPS на бенчмарке (batch=1), т.е. как если бы GPU работал со скоростью 128 Gflops, что в 400 раз ниже, чем заявленные 52 000 Gflops. Тоже самое и с TPU, поэтому Google использует для TPU-edge модифицированные EfficientNet у которых BFLOPS гораздо выше, но и (парадокс) FPS тоже выше.
Т.е. для формальных рейтингов они использую одно, а в продакшене используют совсем другое.
Т.е. пока в значительной степени ускорение акселераторов (TPU, Tensor Cores, ...) дутое.
То ли Google нашел способ как кардинально ускорить DW-conv, SE-block,… в будущих TPU, то ли их показатели Top1/BFLOPS заводят их все дальше в тупик (EfficientNet, MixNet, MobileNetv3, GhostNet, ...), в то время пока nVidia ускорило BIT1-conv, но не спешит ускорять DW-conv.
И это ещё пол беды, у многих других SOTA-нейросетей результаты просто не воспроизводятся и отличаются от заявленных в 2 раза и более.
Но все таки такие штуки как Intel Myriad X, Google TPU Edge и их развитие радуют.
Да, та ваша статья тоже интересная: habr.com/ru/post/455353
Любопытно в ней:
Просто в первом случае:
А во втором случае сравнение Google vs nVidia делала Huawei, которая сравнила не предвзято Google TPU и nVidia GPU, и предвзято выпятила свой Neurochip.
Поэтому может nVidia и забронзовело, но ничего явно лучше, чем nVidia GPU до сих пор нет.
Если акселераторы будут в 100 раз быстрее GPU, то их встроят в GPU (как встроили Tensor Cores), и они уже не будут быстрее GPU :)
Пока что только XNOR-net (используя SVR) удалось ускорить Yolo в 50 раз (FPS/watt) зашив в FPGA: www.researchgate.net/publication/323375650_A_Lightweight_YOLOv2_A_Binarized_CNN_with_A_Parallel_Support_Vector_Regression_for_an_FPGA
Но
1. все таки есть падение точности ~2-4%, требуется обучение используя SVR и есть сложности по использованию новых фишек: mish, weighted-fusion (ASFF, BiFPN, ...),…
2. они сравнили Yolo_v2_float32 (а не bit1) на GPU против Yolo_v2_bit1 на FPGA
3. бинарные операции теперь доступны в Tensor Cores начиная с CC 7.5 — реализация GEMM_BINARY для Yolo-XnorNet на GPU используя Tensor Cores: github.com/AlexeyAB/darknet/blob/dcfeea30f195e0ca1210d580cac8b91b6beaf3f7/src/im2col_kernels.cu#L1224-L1419
Поэтому разрыв будет меньше.
С Новым Годом! :)
Перемножение бинарных матриц на GPU используя Tensor Cores и без них с popcount: https://github.com/AlexeyAB/darknet/blob/53160fa6662ea7e8c4095588db56cac7b339b917/src/im2col_kernels.cu#L1225-L1419
Конкретно в этой строке popcount: https://github.com/AlexeyAB/darknet/blob/53160fa6662ea7e8c4095588db56cac7b339b917/src/im2col_kernels.cu#L1358
На Low-power devices работает до 30 раз быстрее, чем с Float-32-bit.
Высокая точность достигается с применением обучения с online-SVR.
С другой стороны, если мы берем частный случай — блочная разряженность с блоками от 8x8 до 32x32, то можно получить ускорение в ~7x раз на NVIDIA Titan X Pascal openai.com/blog/block-sparse-gpu-kernels
реализация для TensorFlow: github.com/openai/blocksparse
Но что будет с точностью на больших сетях, которые используются в продакшене и больших датасетах — большой вопрос.
Посмотрим когда nVidia реализует блочную разряженность в cuDNN оптимизированной под TensorCores.
Интересно то, что урезанные в 10 раз сети обучаются (сходятся) быстрее и имеют более высокую точность, чем изначально большие сети: https://openreview.net/pdf?id=rJl-b3RcF7
Интересно, что "выигрышные билеты выиграли в лотерее инициализации" и "начальные веса сделали обучение особенно эффективным", следовательно важно не расположение связи, а её инициализация?
На рисунках 9 и 10 показано, что сбрасывание весов (resetting) до начальных выигрышных весов даёт лучшую точность, чем продолжение до-обучения уже обученных выигрышных весов.
Т.е. из 3-х весов:
1. выигрышные, которые сделали обучение особенно эффективными
2. выигрышные, которые сделали обучение особенно эффективными, и обученные
3. совершенно случайные
Для урезанной архитектуры веса-1 получаются самыми лучшими.
1. Главная проблема — полученные разряженные сети не оптимизированы ни под фреймворки, ни под железо NPU/SIMD/TensorCores/… (что намного сложнее изменить). Т.е. прироста скорости не дают никакого.
2. Они делают pruning под конкретный датасет, соответственно, даже если уменьшенная в 20 раз сеть обучается с нуля до той же точности, то она это делает только на этом же датасете. А заранее ты никогда не знаешь на сколько новый датасет сложнее или легче предыдущего.
* Будет датасет сложнее — и точность сильно упадет (урезанная сеть не подходит)
* Будет датасет легче — и можно было бы обрезать весов намного больше (урезанная сеть ещё слишком большая)
3. Они не тестировали на датасетах крупнее MNIST / Cifar.
4. На более глубоких сетях уже начинаются проблемы без warmup.
Полноценной Transactional Memory я так понимаю в ближайшие лет 10 ждать не стоит :) www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4514.pdf