ОС Эльбрус 64-разрядная, однако можно принудительно включить для приложения 32-разрядную адресацию с помощью флага компилятора -mptr32. Обработка по 8 байт работает быстро в дефолтном, 64-разрядном режиме.
Мы использовали внешний цикл в каждом примере. Конкретно в примере 1 было сделано 10000 итераций внешнего цикла. На Core i7 компиляция выполнялась на Microsoft Visual Studio, оптимизация /О2. Одна итерация цикла заняла ~1.5 такта.
Видно, что автовекторизация не случилась, а с Вашим результатом для невекторизованного цикла наш результат согласуется. Раскрутка цикла может дать более эффективное использование конвейера, поэтому на итерацию может уйти меньше 1 такта. Сore i7 — сложный современный процессор, включающий несколько АЛУ, усовершенствованный кэш, Out of Order Execution. Вполне возможно, что в таком простом коде задействовалось сразу несколько разных механизмов повышения производительности :)
По Эльбрус-4С уже опубликовано немало обзоров с результатами более или менее стандартных тестов производительности, 7-zip сжатие/распаковка, например. Для Эльбрус-2С+ есть результаты на SPEC 2000 на сайте МЦСТ. Поскольку мы занимаемся обработкой изображений и распознаванием, нам интереснее рассматривать профильные для нас задачи, которые довольно просто распараллеливаются и хорошо подходят для VLIW-архитектур.
Действительно, энергопотребление мы сравнивали только по TDP, что не совсем корректно, и было бы интересно измерить реальную потребляемую мощность. Возможно мы проведем и такой эксперимент. TurboBoost при замерах мы отключили.
Цель данного поста не сравнить производительность Эльбрус и Core i7, для этого наши примеры не очень подходят. Мы хотели показать, что несмотря на VLIW-архитектуру Эльбруса и написанный специально для нее оптимизирующий компилятор, простые методы оптимизации на нем работают также, как и на Core i7, и в этом смысле разработка программ для Эльбруса не требует дополнительных затрат на специфичную оптимизацию.
Мы не учитывали различия по памяти, поскольку у Эльбрус-4С и Core i7 не только разная скорость ОЗУ, но и разная структура кэш-памяти, алгоритмы кэширования, есть array prefetch buffer на Эльбрус. Поэтому мы использовали более наглядную и простую характеристику.
Ответы, которые мы получили для себя:
1. Процессор — рабочий.
2. Набор инструментов для разработки — имеется.
3. Поддержка и консультации — имеются.
4. Документация — есть (по ГОСТу).
5. Нужная скорость работы нашего софта — достижима (при должной оптимизации).
6. Интересно — очень!
7. Идем ли дальше — да.
Кроме того, в процессе работы над Эльбрусом мы улучшили производительность и на других платформах.
Если кратко, то вот так.
В данный момент мы перешли на следующий этап оптимизации и пока явных барьеров не видим. Вопрос времени и более глубокого изучения возможностей. Мы хотим довести время распознавания до 1 секунды и дальше уже снижать число потоков. А пока что уперлись в лето :)
1. Правильность распознавания проверяется прогоном на референтном датасете (1000 изображений паспортов).
2. Первая рабочая версия — 3 дня работы одного человека, после чего началась оптимизация производительности (3 ч.м.).
3. Для адаптации заменили порядка 100 строчек кода из ~20 мегабайт кода, все изменения обратно совместимы.
4. Оптимизированный код в том же репозитории, вызовы EML под условной компиляцией.
5. Квалификация: студенты и аспиранты, для нас — обычная.
В очень общих чертах алгоритм таков: поиск документа и наведение зон, поиск полей, распознавание полей. Наибольший эффект был достигнут на первом этапе. Про оптимизацию отдельных алгоритмов мы планируем часть 2.
Не можем оспорить ваше утверждение. Действительно, на любой конференции/семинаре после выступлений звучат самые разные заявления. Иногда верные, иногда безумные, иногда возникшие в результате недопонимания. Также ясно, что процитированная вами первая фраза может вызывать весьма эмоциональную реакцию. Однако составлялась она в здравом уме и твердой памяти, и она верна. А эмоциональный фон мог помешать увидеть, что объектом оценки в первой фразе выступает архитектура, а во второй приводятся экспериментальные данные о конкретной модели процессора. Производительность процессора определяется, помимо архитектуры, тактовой частотой (и не только, но не будем усложнять). Тактовая частота определяется в большой степени тех. процессом. Для нас представляется важным, что архитектура действительно является эффективной, как и обещал производитель. Это значит, что мы продолжим тратить своё время (а, следовательно, деньги) на освоение третьей основной для нас архитектуры (после Intel и ARM) в расчете на дальнейшее повышение производительности за счет смены тех. процесса. Догонять по тех. процессу всяко легче, чем усовершенствовать архитектуру. Поймите правильно — продукты мы делаем уже сейчас, производительности хватает. Но, как говорила Черная Королева, «здесь… приходится бежать со всех ног, чтобы только остаться на том же месте». И мы видим у МЦСТ приличный задел на этот самый бег.
Замеченное Вами различие в разы объясняется в-основном следующей причиной:
1) в некоторых страницах текстовая информация занимает мало места, например, в документах типа «Приказ» с простой формулировкой — это способствует быстрому распознаванию;
2) а некоторые страницы напечатаны мелким шрифтом, например, спецификации — это приводит к большим затратам времени Tesseract.
Быстродействие Tesseract для случая с мелким шрифтом снижается при сканировании с малым разрешением (150 dpi).
Также частый случай медленного распознавания — страницы со сложным фоном (например, свидетельства о постановке на учет в налоговом органе), именно для такого фона бинаризация дает ускорение обработки.
Использование медианного фильтра губительно для маленьких шрифтов — съедаются засечки, исчезает внутрибуквенный просвет. В случаях, когда требуется фильтрация, мы используем ускоренный билатеральный фильтр.
Что касается подмешивания шума, то оно может существенно «озадачить» (замедлить) переборные схемы поиска и сегментации строк, когда они основаны на компонентах связности. Нашей же целью было ускорение, а не замедление системы.
Гипотетически, подмешивание шума на фоне существенного замедления могло бы дать некоторое повышение качества, но это справедливо только для алгоритмов, использующих для распознавания растр пониженного разрешения, причем понижающих разрешение усреднением, а не по ближайшему соседу. То есть — совсем не наш случай.
В целом, подмешивание шума при оптимальном (а не завышенном) разрешении изображения — это метод визуализации, улучшения «общего вида» изображения, а вовсе не подходящий для распознавания деталей метод фильтрации.
Раньше мы использовали Microsoft LifeCam Studio — 5 300 руб по яндексу. В процессе создания промышленного образца мы планируем улучшать все характеристики устройства, в том числе и снижать конечную цену.
У нас проблем с перегревом не возникало, Odroid находится под большими нагрузками всего несколько секунд (непосредственно распознавание документа).
Что касается быстрых и медленных ядер, то для наших задач ядра А7 оказываются более, чем в 10 раз медленнее А15. Поэтому при распараллеливании кода мы ограничиваем количество потоков до 4, чтобы помочь операционной системе задействовать именно быстрые ядра.
Проверка на аутентичность нами не производится по нескольким причинам. Во-первых, в видимом свете не так уж и много можно проверить, на части паспортов имеются голограммы, искать голограммы и проверять их мы умеем (в нащем блоге есть две статьи посвященные этому: Статья 1 и Статья 2), но они мешают распознаванию и базовая подсветка сделана так, чтобы они не были видны камере. Для проверки голограмм можно сделать специальную подсветку и разбить цикл работы на этап распознавания и этап проверки подлинности, но это усложнит устройство и не будет работать для старых паспортов и второй страницы паспорта. На старых паспортах можно проверить только, что третья страница паспорта ламинирована. Кроме того, можно проверить грубые нарушения целостности защитных элементов окаймления фотографии, что позволит находить грубые подделки, сделать такой алгоритм у нас в планах. Для более глубокой проверки уже необходимо использовать ИК и УФ диапазоны.
Про скорость по нашему мнению выдача пропуска, заполнение паспортных данных в банке не должна раздражать, вы правильно говорите, что человек не успевает заметить, как уже все — пропуск получен, это его и не раздражает, в этом и состоит наша цель.
Видно, что автовекторизация не случилась, а с Вашим результатом для невекторизованного цикла наш результат согласуется. Раскрутка цикла может дать более эффективное использование конвейера, поэтому на итерацию может уйти меньше 1 такта. Сore i7 — сложный современный процессор, включающий несколько АЛУ, усовершенствованный кэш, Out of Order Execution. Вполне возможно, что в таком простом коде задействовалось сразу несколько разных механизмов повышения производительности :)
Оптимизация — опыт работы 2 и 4 года.
Тесты есть, проходят.
1. Процессор — рабочий.
2. Набор инструментов для разработки — имеется.
3. Поддержка и консультации — имеются.
4. Документация — есть (по ГОСТу).
5. Нужная скорость работы нашего софта — достижима (при должной оптимизации).
6. Интересно — очень!
7. Идем ли дальше — да.
Кроме того, в процессе работы над Эльбрусом мы улучшили производительность и на других платформах.
Если кратко, то вот так.
2. Первая рабочая версия — 3 дня работы одного человека, после чего началась оптимизация производительности (3 ч.м.).
3. Для адаптации заменили порядка 100 строчек кода из ~20 мегабайт кода, все изменения обратно совместимы.
4. Оптимизированный код в том же репозитории, вызовы EML под условной компиляцией.
5. Квалификация: студенты и аспиранты, для нас — обычная.
1) в некоторых страницах текстовая информация занимает мало места, например, в документах типа «Приказ» с простой формулировкой — это способствует быстрому распознаванию;
2) а некоторые страницы напечатаны мелким шрифтом, например, спецификации — это приводит к большим затратам времени Tesseract.
Быстродействие Tesseract для случая с мелким шрифтом снижается при сканировании с малым разрешением (150 dpi).
Также частый случай медленного распознавания — страницы со сложным фоном (например, свидетельства о постановке на учет в налоговом органе), именно для такого фона бинаризация дает ускорение обработки.
Что касается подмешивания шума, то оно может существенно «озадачить» (замедлить) переборные схемы поиска и сегментации строк, когда они основаны на компонентах связности. Нашей же целью было ускорение, а не замедление системы.
Гипотетически, подмешивание шума на фоне существенного замедления могло бы дать некоторое повышение качества, но это справедливо только для алгоритмов, использующих для распознавания растр пониженного разрешения, причем понижающих разрешение усреднением, а не по ближайшему соседу. То есть — совсем не наш случай.
В целом, подмешивание шума при оптимальном (а не завышенном) разрешении изображения — это метод визуализации, улучшения «общего вида» изображения, а вовсе не подходящий для распознавания деталей метод фильтрации.
Что касается быстрых и медленных ядер, то для наших задач ядра А7 оказываются более, чем в 10 раз медленнее А15. Поэтому при распараллеливании кода мы ограничиваем количество потоков до 4, чтобы помочь операционной системе задействовать именно быстрые ядра.
Про скорость по нашему мнению выдача пропуска, заполнение паспортных данных в банке не должна раздражать, вы правильно говорите, что человек не успевает заметить, как уже все — пропуск получен, это его и не раздражает, в этом и состоит наша цель.