Автор: Николай Хабаров, Embedded Expert DataArt, евангелист технологий умного дома.

Python идеально подходит для создания простых PoC-проектов. Всех преимуществ этого языка мы перечислять не будем, обратим внимание на особенность, которая кажется нам одной из самых интересных — кроссплатформенность. Именно благодаря ей Python оказывается очень удобным для создания встраиваемых систем. Не нужно компилировать двоичные файлы, нет необходимости заниматься развертыванием приложений. Тот же код работает как на ПК, так и на одноплатных решениях на базе Linux (например, Raspberry Pi).

Однако у этого подхода есть и свои ограничения. Он не может быть использован для некоторых проектов, требующих определенного оборудования (например, у настольных ПК может не быть и скорее всего не будет SPI, I2C и т. д.). И, конечно же, платы на базе архитектуры ARM работают медленнее, чем персональный компьютер. Поэтому в некоторых случаях алгоритм, отлично работающий на ПК, будет недостаточно производительным на встраиваемой системе.

Высокая производительность была важна для одного из наших последних проектов.



Мы использовали Dragonboard 410c в качестве одной из целевых платформ и были приятно удивлены производительностью платы. Даже без инструментального бенчмаркинга мы заметили значительно более высокую скорость при установке пакетов ОС, запуске приложений и общей производительности по сравнению с Raspberry Pi 3. Давайте посмотрим на спецификации плат:
Плата Raspberry Pi 3 DragonBoard 410c
Процессор BCM2837,
Quad-core ARMA53(v8) 1.2GHz
Snapdragon 410E,
Quad-core ARMA53(v8) 1.2GHz
Память 1GB 1GB

Характеристики примерно одинаковые — они не объясняют лучшую производительность DragonBoard, которую мы видели своими глазами. Поэтому мы провели тест производительности, чтобы убедиться в том, действительно ли эта плата быстрее.

Мы решили измерить на этих платах производительность Python 3 — самой интересной для нас версии этого языка программирования. Мы использовали Python Performance Benchmark Suite, который основывается главным образом на тестах производительности в реальных условиях, а не на синтетических бенчмарках, и использует существующие приложения везде, где это возможно.

Мы использовали нашу любимую ОС для встроенных платформ — Ubuntu Core 16. Это консистентная операционная система с транзакционными обновлениями, которая (что самое главное) поддерживает обе платы, принимающие участие в нашем тестировании. Мы установили Ubuntu Core на SD-карту и использовали snap «classic» для создания традиционной среды ubuntu для проведения теста.

Эта команда устанавливает Pyperformance:

pip3 install pyperformance

Для запуска мы использовали следующие параметры:

echo pyperformance run –python=python3 -o result.json | nohup sudo classic &

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

Вот что мы получили в итоге:



Результаты нас сильно удивили. Производительность DragonBoard почти в два раза выше, чем у Raspberry Pi 3! Конечно, не стоит забывать, что официальное ядро Linux для Raspberry Pi 3 имеет 32-битную архитектуру armhf (v7), а ядро DragonBoard 410c — 64-битную архитектуру amr64 (v8). Вероятно, разница производительности вызвана тем, что Python использует 64-битные вычисления.

Давайте также запустим sysbench — тест, использующий нативный код. Sysbench включает в себя несколько тестов, которые мы хотели бы запустить: cpu, memory, threads, mutex. Эти тесты относятся к более «синтетическим», но в любом случае давайте сравним чистую вычислительную мощность плат. Результаты ниже:
Тест Raspberry Pi3 DragonBoard 410c
cpu
sysbench –test=cpu run
318.1229s 12.6500s
memory
sysbench –test=memory –memory-total-size=2G run
7.5322s 3.0507s
threads
sysbench –test=threads run
23.1469s 9.1600s
mutex
sysbench –test=mutex run
0.0283s 0.0141s

По итогам теста cpu процессор DragonBoard 410c оказался в 25 раз быстрее Raspberry Pi. Это связано с тем, что в тесте cpu используются вычисления с 64-разрядными числами, а в таком случае 64-битная операционная система действительно имеет большое преимущество. Другие тесты показали, что производительность DragonBoard примерно в два раза выше, что в целом соответствует показателям pybenchmark. При этом нужно учесть, что 64-битное ядро не должно влиять на тестирование теста threads.

Конечно, всегда есть возможность разработать свой проект с помощью C или даже одного только ассемблера и получить лучшую производительность. Но обычно время разработки дороже стоимости платы. Использование таких инструментов, как Python, дешевле, эффективнее и производительнее. С их помощью можно создать более качественный продукт и быстрее вывести его на рынок. Снижение производительности, вызванное Python, можно легко преодолеть с помощью более мощной платы. Мы очень надеемся, что официальные мэйнтейнеры выпустят 64-битную версию ядра Raspberry Pi, но на сегодня идеальным выбором для разработки встраиваемых приложений на Python остается DragonBoard 410c.
Поделиться с друзьями
-->

Комментарии (19)


  1. RuddyRudeman
    23.06.2017 21:47
    +4

    Постойте, мы видим двухкратную разницу в производительности между платами с двухкратной разницей в цене. Это не просто удивительно, это удивительно закономерно.


    1. Barnaby
      23.06.2017 23:58

      Прогнал тесты sysbench на Orange Pi PC:
      163.8171s, 6.5875s, 20.6647s и 0.0302s


      Не плохо для платы за 18 баксов.


  1. tmnhy
    23.06.2017 22:19

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


    Странно, почему не консольные мультиплексоры?


    1. RuddyRudeman
      23.06.2017 22:49

      Рискну предположить, что эксперт написал скриптик за вечерок, сварганил csv'шку, скинул в маркетинг и ушел отдыхать, ведь у эксперта не так много времени, чтобы писать всякий pr. А маркетологи написали как умеют, ведь у них в отличии от эксперта не так много реального опыта, чтобы понимать о чем речь.


  1. abstracto
    24.06.2017 02:28

    есть подозрение, что в тесте CPU какая-то ошибка. я лично тестил разные ARMы sysbench'ом, но разницы в 25 раз и близко не было. в принципе хороший медиа ARM в CPU тесте может быть в несколько раз эффективней чем BCM2837, но ни как не в 25 раз. подозреваю, что тест для pi был сделан в один поток, а для DragonBoard в 4 потока(4 ядра).


    1. DataArt
      25.06.2017 18:06
      -2

      Для обеих плат тесты были проведены в 1 поток. Если взгляните на исходные коды теста — то увидите, что там явно используются 64-битные числа. Арифмитические операции 64-битных чисел на 32-битных регистрах может занимать в несколько раз больше тактов, чем арифметика с числами с разрядностью процессора. Было бы у RPI3 ядро, использующее процессор в 64-битном режиме, такой разницы не было бы. Но, к сожалению, официальное ядро, видимо, из-за соместимости с RPI2, делают 32-битным. Так что в этом тесте все закономерно.


      1. abstracto
        25.06.2017 20:50
        +2

        чухня какая-то, простите за мой французский. я делал бенчмарки между 32х битными ARM'ами, между 64х битными и между Intel x86_64 и все цифры были сопоставимы. как минимум между 32 битными и 64 битными ARM'ами разница была в десятки процентов, а не в разы. ну или вы просто разное чисто --cpu-max-prime указали.


  1. aram_pakhchanian
    24.06.2017 08:38
    +2

    Удивительные результаты обычно означают ошибку эксперимента.


  1. izzholtik
    24.06.2017 10:21

    Как у этой платы дела обстоят с драйверами (привет, OpenGL), версией ядра, стабильностью?


    1. gering7
      29.06.2017 15:28
      +1

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


      1. DataArt
        30.06.2017 17:14

        С драйверами и стабильностью дела обстоят очень хорошо, ни разу не было нареканий. А вот со стороны документации и комьюнити дела уже похуже: если потребуется сделать что-то серьезное и/или завязанное на железо, просто нагуглить решение не получится. Raspberry Pi в этом плане, конечно, вне конкуренции.


  1. izzholtik
    24.06.2017 10:27
    +3

    Забавно, кстати, что у любого настольного компьютера есть i2c в составе видеовыходов (VGA, HDMI, etc), в 90% случаев доступный из системы после подгрузки i2c-dev. Я подключал часы реального времени к VGA ноутбука, и они вполне хорошо работали.


    1. izzholtik
      24.06.2017 10:57
      +2

      Собственно говоря, вот пример.
      http://flipthatbit.net/2011/04/interfacing-i2c-the-easy-way/


      1. praeivis
        24.06.2017 12:20
        +1

        То есть, в принципе могу повесит скажем BME280 на VGA порт сервера и мерит температуру и влажность?


        1. izzholtik
          26.06.2017 13:04
          +1

          Попробуйте)
          Подключите монитор и подёргайте i2cdetect с разными шинами. Потом отключите и сравните. Если что-то исчезло, значит, нужную шину вы нашли.
          (не на продакшне, естественно, только Б. Г. знает, что может заглючить на серверном железе при переборе адресов. Ни разу не сталкивался в реальности, но сам писал глючный код работы с i2c)
          Пример с моего компа, VGA разъёмом оказалась шина №7. Результат сканирования с монитором и без него:


  1. Konachan700
    24.06.2017 12:03
    +1

    Разница в 25 раз между схожими армами — явная ошибка. У меня разница в 10 раз на sysbench получилась между Allwinner A20 (ARM, 32bit) и Core2Duo Mobile (х86_64).


  1. ukt
    24.06.2017 13:34

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

    для автоматизации не нужно какого то сверх производительного оборудования.
    для всего остального есть специализированные решения.


  1. erwins22
    24.06.2017 19:50
    +1

    Возможно в одном режиме была компиляция, а в другом интерпритация…
    не доустановили CPython?


  1. IronHead
    25.06.2017 15:34

    Результаты нас сильно удивили. Производительность DragonBoard почти в два раза выше, чем у Raspberry Pi 3!

    Скорее всего, это из за того, что исследование делал:
    Embedded Expert DataArt, евангелист технологий умного дома.

    Был бы обычный инженер или ведущий инженер или инженер с какой то там категорией — то перво наперво — проверил бы свои результаты.

    Узкие места на первый взгляд:
    1) Заниженная частота системной шины у распберри (чтобы плата меньше грелась)
    2) Флеш карта с меньшей скоростью чтения
    3) Не задействованы все ядра
    4) Не сконфигурирована линуха

    По факту — различия между 64 и 32 разрядами на питоне дали бы прирост 10-20% производительности, не более того.