Сравнительное тестирование Smart IDReader на 5 вычислительных комплексах с процессорами Эльбрус

    Smart IDReader — приложение, позволяющее распознавать удостоверяющие документы на различных платформах. Различные режимы распознавания позволяют извлекать данные держателя документа из видеопотока, фотографий или сканов документов.



    Сегодня мы решили рассказать вам о том как мы тестировали Smart IDReader на семействе вычислительных систем Российского производства — Эльбрус. На чем будем тестировать? Как работает распознавание документов на новой машине Эльбрус-8.4? Если интересно, идем под кат.


    Наши предыдущие статьи о распознавании на Эльбрусах:
    https://habrahabr.ru/company/smartengines/blog/304750/
    https://habrahabr.ru/company/smartengines/blog/317672/
    https://habrahabr.ru/company/smartengines/blog/329858/
    https://habrahabr.ru/company/smartengines/blog/340918/


    На чем будем тестировать?



     
    В обзоре участвуют 5 различных устройств на основе процессоров Эльбрус:


    Эльбрус 101-РС


    Эльбрус 101-PC — компактная рабочая станция на базе микропроцессора Эльбрус-1С+ с системным блоком в формате nettop, отличающаяся малым уровнем шума. Сам процессор Эльбрус-1С+ имеет встроенный ускоритель 3D-графики, поддерживающий OpenGL 2.1 и OpenCL 1.2, и потребляет не более 25 Вт электроэнергии, благодаря чему хорошо подходит для встроенных систем и переносных терминалов.



     


    Эльбрус 401-PC


    Эльбрус 401-PC — персональный компьютер на базе микропроцессора Эльбрус-4С, который уже неоднократно фигурировал в наших обзорах.



     


    Сервер Эльбрус-4.4


    Сервер Эльбрус-4.4 — 4-процессорный сервер на базе Эльбрус-4С, оснащенный 96 ГБ оперативной памяти. На таком мощном сервере можно решать сложные вычислительные задачи, использовать для различных серверных приложений или просто хранить данные.



    (вывод обрезан)
     


    Эльбрус 801-РС


    Эльбрус 801-PC — рабочая станция на базе микропроцессора Эльбрус-8С, вышедшего в прошлом году. Эльбрус-8С имеет усовершенствованную архитектуру: поддерживает выполнение до 25 операций за 1 такт, а также работает на частоте до 1300 МГц. На нашем образце в момент экспериментов тактовая частота была снижена до 1200 МГц.



    (вывод обрезан)
     


    Эльбрус-8.4


    И, наконец, новая разработка МЦСТ и ИНЭУМ им. Брука: 4-процессорный серверный модуль на основе Эльбрус-8С с 10-гигабитным интерфейсом Ethernet М10GE/E собственной разработки МЦСТ, обеспечивающим доверенное соединение между узлами. Он предназначен для использования в качестве узла хранения, обработки и передачи данных или решения других задач, на которые хватит фантазии.


    Характеристики Эльбрус-8.4


    Наименование параметра Значение
    Наименование микропроцессора Эльбрус-8С (1891ВМ10АЯ)
    Количество ядер в микропроцессоре, шт. 8
    Максимальная тактовая частота микропроцессоров, ГГц до 1.3
    Количество микропроцессоров в вычислительном устройстве, шт. 4
    Объем оперативной памяти, Гбайт до 256 ГБ ОЗУ с коррекцией ошибок (ЕСС)
    Система охлаждения встроенная, воздушного типа
    Каналы ввода-вывода 3 разъема сети Gigabit Ethernet
    3 разъема PCI Express
    1 разъем шины RS-232
    4 разъема шины USB
    1 разъем видео VGA
    Электропитание 220 ± 22 В, 50 ± 1 Гц
    Потребляемая мощность, Вт, не более 500
    Рабочий температурный диапазон −10 C … +50 C


    (вывод обрезан)


    На нашем образце в момент экспериментов тактовая частота была снижена до 1200 МГц.


    Теперь приведем характеристики всех тестируемых машин вместе:


    Машина Эльбрус 101-PC Эльбрус 401-PC Эльбрус-4.4 Эльбрус 801-PC Эльбрус-8.4
    Процессор Эльбрус-1С+ Эльбрус-4С Эльбрус-4С Эльбрус-8С Эльбрус-8С
    Число ядер общего назначения 1 4 16 8 32
    Тактовая частота, МГц 985 800 750 1200 1200
    Число операций за такт (на ядро) до 25 (8 цел., 12 веществ.) до 23 до 23 до 25 (8 цел., 12 веществ.) до 25 (8 цел., 12 веществ.)
    Технологический процесс 40 нм 65 нм 65 нм 28 нм 28 нм
    Устройство хранения данных 120 ГБ SSD mSATA 3.0 120 ГБ SSD mSATA 2.0 500 ГБ HDD 3.5’’ SATA2.0 120 ГБ SSD mSATA 3.0 2 ТБ HDD 3.5’’ SATA3.0
    Объем ОЗУ с коррекцией ошибок (ECC) 16 ГБ 24 ГБ 96 ГБ 32 ГБ 128 ГБ
    Число транзисторов (на процессор) 375 млн. 986 млн. ~986 млн. 2,73 млрд. ~2,73 млрд.
    L1 кэш (на ядро) 64 КБ данные + 128 КБ команды 64 КБ данные + 128 КБ команды 64 КБ данные + 128 КБ команды 64 КБ данные + 128 КБ команды 64 КБ данные + 128 КБ команды
    L2-кэш (на ядро) 2 МБ 2 МБ 2 МБ 512 КБ 512 КБ
    L3 кэш (общая) - - - 16 МБ 16 МБ

    Ширина SIMD инструкции для всех процессоров составляла 64 бита.


    Протестированные документы


    Мы решили рассмотреть распознавание 6 достаточно разных типов документов. Это:


    Паспорт РФ



     
    Биометрический паспорт РФ



     
    Водительские права РФ



     
    Водительские права Великобритании



     
    Немецкие ID-карты



     
    Лист нетрудоспособности (больничный лист)



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


    Оценка производительности


    Для оценки производительности Smart IDReader мы измеряли чистое время распознавания одного скана или фотографии без учета загрузки изображения из файла, а также без учета загрузки файлов конфигурации. При этом документ на изображении может быть произвольным образом повернут. Время распознавания усреднялось по 100 изображениям каждого документа.


    Наше приложение было скомпилировано под архитектуру Эльбрус из исходного кода с помощью компилятора lcc 1.21.19 и запускалось в нативном режиме. Распараллеливание выполнялось на максимально доступное число потоков при помощи библиотеки tbb.


    Сначала мы запустили последовательное распознавание (время на одно изображение):


    Эльбрус 101-PC Эльбрус 401-PC Эльбрус-4.4 Эльбрус 801-PC Эльбрус-8.4
    Паспорт РФ 3.87 с 1.90 с 1.80 с 1.21 с 1.09 с
    Биометрический паспорт РФ 3.33 с 1.85 с 1.80 с 1.10 с 1.05 с
    Водительские права РФ 4.24 с 2.12 с 1.81 с 1.24 с 1.09 с
    Водительские права Великобритании 2.26 с 1.08 с 1.03 с 0.69 с 0.66 с
    Немецкие ID-карты 2.32 с 1.22 с 1.13 с 0.77 с 0.72 с
    Больничный лист 7.59 с 3.40 с 2.65 с 1.97 с 1.49 с

    В более наглядном виде:



    Можно видеть, что мы не сидели сложа руки: с нашей прошлой статьи время распознавания паспорта РФ уменьшилось в 1.5 раза как на 401-РС, так и на 801-PC и стало меньше 2 секунд. А вот распознавание больше, чем в 4 потока, не дает значительного прироста производительности на всех документах, кроме больничного: все-таки в паспорте распознается всего 12 текстовых полей, а в водительских правах и ID-картах — и того меньше: 7. Поэтому распараллеленной оказывается не такая большая часть алгоритма, что, конечно, является минусом для распознавания отдельных изображений документов на многоядерных системах. Больничный лист содержит значительно больше полей, поэтому ускорение между 401-РС и Эльбрус-4.4 и 801-РС и Эльбрус-8.4 заметнее. Также стоит отметить, что 101-PC с одним ядром работает всего вдвое медленнее, чем 401-PC. Так происходит потому, что в 101-РС стоит процессор Эльбрус-1С+ новой ревизии, поддерживающий исполнение до 25 операций за такт и работающий на частоте 950 МГц, а вот в 401-РС — старый Эльбрус-4С, выполняющий до 23 операций за такт (ну и от закона Амдала никуда не деться :))


    Однако на многоядерных системах можно запустить Smart IDReader в серверном режиме: запустить несколько процессов распознавания документов параллельно. В таком режиме мы сможем полностью загрузить все ядра процессора и более реалистично оценить производительность соответствующих устройств.


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


    Результаты при полной загрузке Эльбрусов (среднее время на одно изображение):


    Эльбрус 401-PC Эльбрус-4.4 Эльбрус 801-PC Эльбрус-8.4
    Паспорт РФ 1.27 с 0.36 с 0.43 с 0.11 с
    Биометрический паспорт РФ 1.13 с 0.36 с 0.42 с 0.11 с
    Водительские права РФ 1.79 с 0.47 с 0.64 с 0.16 с
    Водительские права Великобритании 0.93 с 0.26 с 0.32 с 0.08 с
    Немецкие ID-карты 0.99 с 0.26 с 0.37 с 0.10 с
    Больничный лист 2.22 с 0.66 с 0.86 с 0.22 с

    Результаты в виде диаграммы:



    По этим результатам видно, что серверные модули на основе Эльбрусов вполне соответствуют заявленным характеристикам и для задач с высокой степенью параллелизма демонстрируют ускорение в 3-4 раза. При этом сервер Эльбрус-4.4 все еще на 20-30% мощнее рабочей станции Эльбрус 801-РС. Сравнение 401-PC и 801-PC также не принесло неожиданностей: 801-PC практически в 3 раза быстрее своего предшественника за счет повышения тактовой частоты и значительного усовершенствования архитектуры. Для Эльбрус-4.4 и Эльбрус-8.4 это соотношение сохранилось.


     
    Мы очень благодарны компании и сотрудникам МЦСТ и ИНЭУМ им. Брука за возможность протестировать новый серверный Эльбрус-8.4 и хотим пожелать им и дальше радовать нас достойными разработками!


    Поздравляем всех с наступающим и желаем профессиональных успехов, здоровья и счастья в новом 2018 году!

    Smart Engines 47,46
    Обработка изображений, распознавание в видеопотоке
    Поделиться публикацией
    Комментарии 15
    • +9
      Спасибо, интересно. Однако сравнения с Intel / ARM очень не хватает.
      • 0
        Вот тут мы проводили сравнение
        • 0
          Спасибо. То есть, если нормировать на гигагерц — то МЦСТ раза в 2 быстрее intel. Если не нормировать — раза в два медленнее. А если нормировать на стоимость?
          • 0
            Долго вы на эту лажу еще ссылаться будете?
            • 0
              Все это, конечно, хорошо, но в обоих сравнениях не хватает важной группы контрольных тестов: тестов на динамику производительности в пересчете на гигагерц для одной и той же модели процессора при разной тактовой частоте. Возможно ли проведение таких тестов? И вообще, насколько возможен разгон процессоров «Эльбрус»?
            • 0
              Простите, что тревожу. А почему именнно этого не хватает? Вот именно такого сложносочиненного тройного сравнения? Если бы Вам не хватало только сравнения с Intel, я бы рискнул справиться с этой загадкой сам. Хотя и в этом случае не совсем ясно, почему не интересно сравнивать с VIA. Особенно двадцатипятиваттовку. Но вроде бы и персоналки на ARM, и мобильники на Эльбрусах выглядят сейчас одинаково дико, хотя, возможно, и по разным причинам. Тогда в чем смысл?
              Или вот возьмем, к примеру, сайт IXBT. Их обзоры весьма комментатороориентированы, поскольку именно в этом их бизнес измеряется — в активных читателях. Не затруднит ли Вас «прикидочно» сказать, насколько часто там сравниваются ARM и Intel в сравнении с числом обзоров, когда сравниваются процессоры одной линейки?
              Вообразим человека, которому интересно, чтобы кто-то другой сравнил Эльбрус и KOMDIV-64. Кто он? Возможно, фанат военной техники. Нет загадки.
              Или пусть будет некто, кому интересно сравнение с Loongson третьего поколения. Тоже понятно. Разные национальные немэйнстримовые решения. Чей подход удачнее? Или интереснее сравнить с Zhaoxin ZX-D? Тут и национальный колорит, и x86 в одном флаконе.
              Сравнение с Intel, но именно с брошенным Itanium — еще любопытнее. Очень не хватает. Что можно выжать из VLIW архитектуры, если вложить по-настоящему много?
              Но, ради Бога, не мучьте, почему одновременно с Intel и ARM?
              • 0
                Я не автор вопроса, но рискну предположить причины (хотя бы потому, что мне самому ответ интересен).
                Причина первая — интересно, могут ли военные на госконтрактах догнать конкурирующие корпорации. Ответ — похоже, не могут. Хотя и пытаются не отставать совсем уж навсегда (за что им, кстати, честь и хвала, без шуток).
                Причина вторая — если условно завтра условные дроны условных террористов с intel+nvidia в голове будут воевать с государственными дронами, у которых в голове Эльбрус, у кого будет преимущество в производительности? То-то. И в разумное время это не изменится. Следовательно, ребята будут сильнее упарываться в оптимизацию алгоритмов, тюнинг и т.п. — значит, у известных мне околовоенных программистов ещё долго будет дофига работы и хантить их бессмысленно — скорее всего, военные будут вынуждены за них держаться крепко.
                Как-то так. А вы говорите, зачем сравнивать.
                • 0
                  Начинка «условных дронов» также должна соответствовать требованиям к надёжности (температура среды, перегрузки, радиация и т.п.). Это, пожалуй, будет поважнее скорости.
                  • 0
                    Преимущество будет у китайцев, обслуживающих и Nvidia и Intel, и МЦСТ. С их места обзор будет великолепен
                  • 0
                    Вполне адекватный вопрос. Человека интересует сравнение с двумя наиболее актуальными и перспективными сейчас платформами. К чему тут троллинг про VLIW и Itanium мне, к примеру, в принципе не понятно.
                    ARM как серверная платформа уже не дикость, кстати
                    www.theregister.co.uk/2017/03/09/microsoft_arm_server_followup
                    techcrunch.com/2017/06/22/scaleway-doubles-down-on-arm-based-cloud-servers
                • 0
                  Промазал.
                  • –2

                    Как блин приложение и машина подходят друг для друга

                    • 0
                      Не пробовали использовать специально разработанную высокопроизводительную библиотеку eml от производителя Эльбрусов?
                      • 0
                        Мы используем и библиотеку EML, и специальный набор интринсиков от производителя.
                      • –1
                        Эльбрус опять варится в своей песочнице.

                        «Мы используем и библиотеку EML, и специальный набор интринсиков от производителя.»
                        Почему-то для Э использовали EML, а для Intel использовали всего лишь SSE. SSE конечно SIMD, но как бы — это всего лишь 128-битные инструкции, в то время как есть уже 256 битные и давно. Да и 512-битные уже есть на сейчас.

                        Для Интел есть MKL — почему не использовали? Вопрос риторический конечно же.

                        Собственно, в таких тестах легко получить нужные результаты и проконтролировать их практически нереально — поэтому необходимо доверие к автору. А тут всего скорее человек заинтересован и тут уж сложно доверять на все 100. Лакмусовой бумажкой таких обзоров для меня выступает сравнение производительности на мегагерц, которое вообще не понятно каким образом относится к производительности. На Вт я бы еще понял, но какой смысл на МГц? P4 на 90нм брал 3.8ГГц. Sandy Bridge на 32нм брал 4ГГц. А если тут у Э8 на 28нм всего 1.3ГГц — архитектура такая.

                        Те, кто интересуется, давно уже видели результаты SPEC 2006. И там как бы все ясно, что все плохо.

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

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое