Я видел много реализаций сверточного слоя в разных библиотеках. Во многом они совпадают. Может потому, что код у всех открытый, а может люди независимо приходят к похожим вещам. Это в принципе не так важно. Я лишь хотел раскрыть для заинтересованного читателя, как это все устроено.
C 2013 года я переключился на другие проекты. На AntiDupl не хватает времени и сил. Впрочем ей я и так посвятил почти 11 лет своей жизни. Если у вас есть энтузиазм — там люди на проекте не помешали бы.
Да было время… Была своя коллекция музыки, фильмов, картинок. Для последних даже написал прогу, чтобы избавляться от дубликатов в автоматическом режиме. Сейчас кажется смешным, а раньше была радость — вот удалил пару десятков мегабайт дублирующих картинок.
2) Скорость кода может катастрофически (до 10 раз) меняться в зависимости от того, влазят расчетные данные в процессорный уеш или нет. Потому любой быстрый алгоритм должен разбивать/сливать исходные данные такми образом, что бы кеш использовался максимально эффективно. В Synet и Inference Engine немного разный подход, но основные принципы совпадают.
4) Не знаю, VFP — вроде как аналог x87 и считается устаревшим в ARMv7 и ARMv8. Везде рекомендуют вместо него использовать NEON. Единственное его преимущество — поддержка FP64. Но почитаю про него по подробнее.
1) Возможно я не прав.
2) Synet тоже оптимизирует свёртки и их последовательность для оптимального использования памяти. Благодаря чему и достигается преимущество в производительности.
3) Согласен. Добавлю в цели :).
4) Под сопроцессором вы встроенный GPU имеете в виду?
1) Наболее быстрая реализация OpenCV на процессорах Интел реализовано как раз на OpenVINO (Inference Engine там под капотом). Потому зачем тащить OpenCV, если можно сравнить напрямую.
2) По умолчанию OpenVINO включает распараллеливание на все ядра, как и другие фреймворки. Может поэтому у вас сложилось такое впечатление. Если я не прав — поправьте.
3) У нас на проекте используется два вдижка (Inference Engine и Synet) — взависимости от того что быстрее, то и используется. Потому с целью облегчения своей работы, я ограничился конвертацией из OpenVINO — благо в этот формат так и так надо перегонять.
4) Raspberry Pi поддерживается. Впрочем как и любой ARM с поддержкой NEON.
На самом деле тут не сложно подсчитать: при скорости света в 300000 км/с и частоте в 50 Гц длина волны будет 6000 км. Два источника переменного тока уже на расстоянии в 1500 км будут полностью разсогласованы. На практике переменным током передают обычно максимум на 300 км.
Здесь видится некоторое непонимание ситуации. Что постоянный, что переменный ток имею практически одинаковые потери при передачи по проводам. Но! Что бы потери при передачи на растоянии были меньше, нужно высокое напряжение. А для переменного тока можно легко менять напряжение при помощи трансформатора практически со 100% КПД. Если расстояние становится слишком большим (несколько тысяч км), то у переменного тока возрастают потери на согласование фаз. И тогда уже выгоднее передавать постоянный ток, даже не смотря на его большие потери при преобразованиях.
К сожалению нет. На первый взгляд действительно все проще: данные A и B лежат одинаково — только считай взаимное скалярное произведение их строчек.
Однако: максимальный размер микроядра получится 3x4, что дает нам (3 + 4)/(3*4) = ~0.58 загрузок на одну fma. Напомню, что при классической схеме с окном 6x16 получается (6 + 16)/(6*16) = ~0.23 загрузок на одну fma. Т.е. предложенная вами схема почти в 2.5 раза более требовательна к пропускной способности памяти. В принципе мои внутренние тесты это подтверждают.
Цитата из введения: С целью ограничить объем изложения, я ограничился описанием однопоточного алгоритма для обычных процессоров. Тема многопоточности и алгоритмов для графических ускорителей явно заслуживает отдельной статьи.
4) Не знаю, VFP — вроде как аналог x87 и считается устаревшим в ARMv7 и ARMv8. Везде рекомендуют вместо него использовать NEON. Единственное его преимущество — поддержка FP64. Но почитаю про него по подробнее.
2) Synet тоже оптимизирует свёртки и их последовательность для оптимального использования памяти. Благодаря чему и достигается преимущество в производительности.
3) Согласен. Добавлю в цели :).
4) Под сопроцессором вы встроенный GPU имеете в виду?
2) По умолчанию OpenVINO включает распараллеливание на все ядра, как и другие фреймворки. Может поэтому у вас сложилось такое впечатление. Если я не прав — поправьте.
3) У нас на проекте используется два вдижка (Inference Engine и Synet) — взависимости от того что быстрее, то и используется. Потому с целью облегчения своей работы, я ограничился конвертацией из OpenVINO — благо в этот формат так и так надо перегонять.
4) Raspberry Pi поддерживается. Впрочем как и любой ARM с поддержкой NEON.
Однако: максимальный размер микроядра получится 3x4, что дает нам (3 + 4)/(3*4) = ~0.58 загрузок на одну fma. Напомню, что при классической схеме с окном 6x16 получается (6 + 16)/(6*16) = ~0.23 загрузок на одну fma. Т.е. предложенная вами схема почти в 2.5 раза более требовательна к пропускной способности памяти. В принципе мои внутренние тесты это подтверждают.