Всех приветствую, в данной статье разберём , насколько рационально покупать SBC на ARM, чем неттопы на старых процессорах Intel x86 серии N и U. Рассмотрим именно старое поколения чипов Intel из-за того, что они подешевели и находятся  в том  же ценовом сегменте, что и SBC на ARM. Детально рассмотрим далее в статье.

Участники тестирования

В данной статье, для сравнения, будут участвовать ноутбук с Intel Pentium 4417U (который будет представлять условный неттоп). Данный процессор, максимально похож по производительности в многопотоке Intel Pentium N6000. Также, как и старые представители Intel N-серии, не имеет векторных инструкций, но зато, быстрее их в один поток. ARM SBC будут представлять двумя платами – Raspberry Pi 5 (Broadcom BCM2712) и Orange Pi 5 (Rockchip RK3588S). Если первый появлялся в статьях и ранее, то второй ещё не появлялся, поэтому его также интересно сравнить как и с Broadcom BCM2712, так и с Intel Pentium 4417U. Характеристики конкурсантов приведены ниже в таблице.

Процессор	Intel Pentium 4417U	Broadcomm BCM2712	Rockchip RK3588S
Архитектура ядер	Kaby Lake-R	Cortex-A76	Cotrex-A76/Cortex-A55
Количество ядер	2	4	4+4
Количество потоков	4	4	8
Частота ядер, ГГц	2,3	2,4	2,4+1,8
TDP, Вт	15	10	15
Тип поддерживаемой ОЗУ	LPDDR3, DDR3, DDR4	LPDDR4/4X	LPDDR4/4X,LPDDR5
Ширина шины ОЗУ, ,bn	128 (64*)	32	64
Объём L1 кэша на ядро, КБ	32	64	64/32
Объём L2 кэша суммарно, МБ	0,5	2	2,5
Объём L3 кэша суммарно, МБ	2	3	3
iGPU	Intel UHD 610	Videocore VII	Mali G610 MP4
Количество блоков iGPU	12	12	4
Частота IGPU, МГц	950	1000	1000********
Максимальная версия OpenGL	4.6******	3.1*****	- (3.1)***
Максимальная версия OpenGL ES	3.2	3.1	3.2(3.1**)
Максимальная версия Vulkan	1.3*******	1.3	1.2(1.1**)
Максимальная версия OpenCL	2.1	2.0********	2.2****
Используемая ОС	Ubuntu 24.04	Debian 12	Ubuntu 24.04
Версия ядра	6.11	6.6	6.1

Примечания:

* - ограничение по ширине шины ОЗУ, связан с материнской платой, на которой нет 2-го разъёма ОЗУ

** - из-за драйверов под Linux (Panfrost), Mali G610 не умеет работать с максимально возможными версиями API

*** - Данные об аппаратной максимально поддерживаемой версии OpenGL отсутствуют. В системе с драйвером Panfrost, доступен  OpenGL версии 3.1

**** -  на Panfrost, OpenCL не работает

***** - информация взята с glxinfo

****** - в спецификациях указана версия 4.4, но драйвер выводит информацию о версии 4.6

******* - в спецификациях указана версия 1.2, но драйвер выводит информацию о версии  1.3

******** - информация основана на информации из сторонних источников и является не проверенной

Также в таблице указаны версии ядер и дистрибутивы Linux из-за возможного влияния на производительность определённой версии ядра, что особенно касается ARM SBC.

Тестирование в бенчмарках

Начнём тестирование с различных бенчмарков. Представителями браузерных тестов будут Octane V2, Jetstream, Mozilla Kraken. Также тестирование будет проводиться в sysbench, 7z, tinymembench, glmark2, vkmark, llama.cpp, Phoronix test suite (используем 1 тест – nginx на 4000 запросов) и core-to-core-latency.

Теперь перейдём к браузерным тестам:Если по BCM2712 и RK3588S всё понятно – одинаковое ядро Cortex-A76 и частота в 2,4 ГГц и производительность будет одинакова. С P4417U ситуация другая, если в Octane и в Jetstream у всех результаты приблизительно одинаковы, то в Mozilla Kraken он опередил всех на 14%.

Перейдём к sysbench. Начнём с производительности CPU:В один поток, быстрее всех оказался BCM2712 и на 7% отстал RK3588S (но это может быть погрешность, что более вероятно) и на последнем месте оказался P4417U с 3-х кратным отставанием от остальных. Но если посмотрим на многопоток, то на первом месте будет RK3588S (за счёт количества ядер), а на втором, будет BCM2712 с 20% отставанием от лидера и аутсайдером оказался P4417U – он оказался в 4 раза медленнее, чем BCM2712.

По оперативной памяти, другая ситуация: Одинаково себя выступили P4417U и BCM2712 и они оба отстали от RK3588S при чтении на 31%, а при записи  - на 24%.

От sysbench перейдём к 7z. Начнём с упаковки:

 
Видим, что производительность P4417U и BCM2712 приблизительно одинаковая, в то же время, RK3588S быстрее их двоих на 114%, что довольно таки много. Перейдём к распаковке:

В случаи с распаковкой, то P4417U оказался на последнем месте и отстал от BCM2712 на 90%, а в свою очередь, BCM2712 отстал от RK3588S на  41%. Разрыв между первым и последним местом, составил внушительные 173%.

Теперь перейдём к графическим тестам. Начнём с glmark 2:Как видим, отстала UHD610, но при этом, Videocore VII смогла подтянуть результаты, в сравнении с результатами тестированием полгода назад (смотрите прошлые результаты тут) ну и победителем оказался Mali G610 MP4. UHD 610, отстал, соответственно, от Videocore VII на 16% и от Mali G610 MP4 на 78%.

В vkmark другая ситуация:Быстрее всех оказался UHD610, на втором месте Mali G610 MP4 и на третьем – Videocore VII. UHD 610, быстрее остальных на  42% и 98% соответственно.

Теперь перейдём к самому интересному – тест в llama.cpp. Результаты тестирования приведены ниже:


Во всех случаях использовался CPU. Аппаратное ускорение ИИ с помощью различных API (даже API Vulkan) не доступны на тестируемых платформах. Начнём с pp512. На вход не так всё плохо для ARM SBC. Тут BCM2712 отстаёт RK3588S на 22%. Очень сильно отстал P4417U, у которого нет векторных инструкций и он отстал от BCM2712 в 24,8 раза. По выходу ситуация немного другая – BCM2712 довольно сильно отстал от RK3588S на 158,8%, в то время, как P4417U показал плачевный результат – 0 т/с. Перейдём к tg128 – расстановка тут слегка поменялась. На входе видно, что BCM2712 отстаёт от RK3588S в 2 раза, а P4417U в 10 раз (что лучше, в сравнении с pp512). На выходе расстановка та же, за исключением того, что P4417U выдал тот же нулевой результат.

Перейдём к Phoronix test suite с его подтестом nginx.Как видим, P4417U отстал от BCM2712 на 25%, а вот BCM2712 отстал от RK3588S на 52%. В то же время, разница между первым и последним местом составила 88%.

Теперь перейдём к tinymembench. Тут результат тоже интересен. Начнём с теста пропускной способности.

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

	RK3588S	BCM2712	P 4417U
C copy backwards	11945,5	5147,7	5417,7
C copy backwards (32 byte blocks)	11934,7	5194,4	5409,4
C copy backwards (64 byte blocks)	11916,9	5171,8	5418,8
C copy	12345,6	5162,8	5467,2
C copy prefetched (32 byte blocks)	12590,7	5172,8	5473,7
C copy prefetched (64 byte blocks)	12656,5	5173	5473
C 2-pass copy	5269,2	5049,4	4850,8
C 2-pass copy prefetched (32 byte blocks)	9675,7	5327,6	4856,4
C 2-pass copy prefetched (64 byte blocks)	10334,9	5328,1	4863,4
C fill	29726,2	9963,7	8050,3
C fill (shuffle within 16 byte blocks)	29165,9	9954,2	8036,4
C fill (shuffle within 32 byte blocks)	29363,3	9971	8069,4
C fill (shuffle within 64 byte blocks)	29136,3	9958	8063,9
standard memcpy	12556,8	5156,3	8075,9
standard memset	29171,5	9985	17279,4

Как видим, по всем показателям, сильно отрывается RK3588S. А вот что можно сказать про BCM2712 и P4417U – я бы сказал, что они равны, хотя BCM2712 имеет преимущество в некоторых тестах, но не всех, а в одном даже уступает.

Перейдём к самому интересному – задержки в кэшах и ОЗУ: Зависимость и соотношения от 1 процесса и от 2 одинакова, так что, данный момент рассматривать не будем. Если по задержкам кэшей у всех всё одинаково, то по ОЗУ не так всё гладко. Отмечу, что у P4417U и RK3588S подключена память по 64 битной шине, а в BCM2712 – по 32 битной шине.  Видим, что по задержкам сильно отстаёт RK3588S, с большим отрывом, лучше задержки у BCM2712. А самые лучшие задержки у P4417U, хоть и не с большим отрывом от BCM2712, но явно впереди. Рассмотрим межядерные задержки в наносекундах с помощью core-to-core-latency:

Intel Pentium 4417U
Rockchip RK3588S

Broadcomm BCM2712

Как видим, самые большие межядерные задержки у RK3588S – 65 нс (но они одинаковые по всем ядрам). На втором месте по задержкам BCM2712 – 29-30 нс и на первом месте по межядерным задержкам находиться Pentium 4417U – порядка 14 нс, но почему-то, при обращении к виртуальным потокам, задержки высокие и с чем это конкретно связано – сказать сложно, с другими процессорами с гиперпоточностью, таких проблем не было.

Тестирование в рабочих задачах

В этом разделе, тестирование будем проводить с помощью ffmpeg и компиляции программы из исходных кодов (в данном случаи – llama.cpp). Начнём с ffmpeg. Используя только CPU для перекодирования видео из HEVC в H264, получим вот такой результат:Дольше всех перекодировал P4417U, на 23% быстрее это сделал BCM2712 и ещё на 44% быстрее это сделал RK3588S, при этом, разница между первым и последним местом, составила 78%. Но если включить аппаратное ускорение, то BCM2712 сразу выбывает, так как ему перекодировать нечем, а вот у других конкурсантов есть чем. Эти результаты приведены ниже:Как видим, что хоть результат у RK3588S меньше, но разница не такая большая, как была – 56%, много конечно, но приемлемо. Но если посчитать насколько ускорило аппаратное ускорение, то получится обратная картина – если в случаи P4417U аппаратное ускорение уменьшило время перекодирования в 18 раз, в то же время, с RK3588S, данная цифра составила в 16 раз, что чуть меньше, но тоже неплохо.

Перейдём к компиляции программы (llama.cpp):Если P4417U и BCM2712 различаются между собой на 10%, то RK3588S быстрее второго на 26%. Разница между первым и последним местом составила 35%.

Тестирование в играх

Ну и теперь тестирование в играх. Для этого, с учётом возможной встроек SBC, были взяты всего две игры – Minetest (настройки по умолчанию) и Minecraft 1.16.5 (Разрешение экрана: 1920х1080, Графика: Детально, Мягкое освещение: Максимум, V-Sync: Выкл, Уровни детализации: 4, Прорисовка: 8 чанков, Частота Кадров: Максимум, Облака: Объёмные, Частицы: Все, Тени сущностей: Вкл). Начнём с первой игры:

Как бы странно это не было, RK3588 и BCM2712 имеют одинаковую однопоточную производительность, а вот P4417U показал своё преимущество в однопотоке, но упёрся в лимит кадров, но сам факт того, что в один поток данный чип быстрее, интересен. Теперь переходим к следующей игре – Minecraft. 

Как видим, несмотря на  бенчмарки, самой быстрой встройкой оказалась IGPU UHD610, если RK3588S отстал вместе с Mali G610 MP4 всего на 45%, то, BCM2712 показал самый худший и неиграбельный результат с отрывом от первого места в 4 раза.

Выводы

По итогу, были получены неоднозначные результат. Intel Pentium 4417U показал себя неплохо, несмотря на плохие результаты в некоторых бенчмарках и тестах. Несмотря на хорошее выступление, всё же, младшие процессоры «старой школы» от Intel (к таким можно причислить Pentium и Celeron U линейки до 10 поколения включительно и процессоры N серии, вплоть до Alder Lake-N) во многих аспектах устарели. Рассмотрим данные аспекты:

• Отсутствие векторных инструкций, может замедлить работу программы, в сравнении с современными ARM SBC (ffmpeg) или другими представителями x86-64 или вовсе уменьшить скорость работы программы до минимума (llama.cpp)
• Отмечу, что в процессорах линейки N старого образца, однопоточная производительность будет ниже, чем U серии, значится, будет хуже результаты во многих однопоточных дисциплинах, но в многопоточных – если у процессора с обозначением Nxxxx будет 4 ядра то и будет, всё нормально (во многопотоке), если 2 – это катастрофа, данные процы отстанут от довольно сильно от представленных  в данной статье 

Но отмечу, несмотря на это, можно констатировать следующее:

• В задачах, где не требуются векторные инструкции, данные процессоры могут на равных бодаться с процессорами на ARM SBC и даже их превосходить (что можно видеть по тестам)
• На борту данных чипов, имеется хороший декодер, который может смягчить слабость процессорных ядер в мультимедийных задачах, за счёт хорошей производительности декодера/энкодера (что было показано на примере ffmpeg)

Отмечу, несмотря на результаты бенчмарков, но если судить по тому же Mozilla Kraken и Minetest, то можно сказать, что когда не требуются векторные инструкции, P4417U будет быстрее ARM SBC в один поток, что повлияло и на многопоток, что позволило тому же P4417U на равных бодаться с BCM2712  в многопоточных задачах, а с RK3588S уже не получилось (что ожидаемо). Вот такая ситуация выходит в случаи с процессорами Intel.

Если же коснёмся ARM SBC, то тут ситуация другая. В данном случаи, были представлены топ SBC, которые есть на данный момент. И если для сравнения взять более слабые чипы, картина радикально измениться. Из-за отсутствия векторных инструкций (что актуально для чипов, у которых нет ядер с поддержкой ARM v8.2, а именно, Cortex-A76 и Cortex-A55 и выше) и сами по себе более слабой производительностью, показали бы довольно проигрышные результаты, они бы уступили много чему. А если перейти к топ платам на топ чипах, на текущий момент, они показали себя очень неплохо – если BCM2712 был всегда чуть быстрее или на уровне P4417U (за исключением 2-х тестов), то RK3588 оторвался довольно таки далеко, что и от BCM2712, что и от P4417U.

Если рассмотреть с точки зрения встроенной графики, то картина меняется – на первом месте оказался Intel UHD 610 (несмотря на результат теста в glmark2), на втором – Mali G610 MP4 в составе RK3588S. Он хоть и отстал, но выступал неплохо и на него больше всего влияет используемый открытый драйвер Panfrost (из-за того, что там пока не всё реализовано и из-за этого может быть ниже производительность, но отмечу, что в дальнейшем, ситуация может поменяться). А на третьем месте оказался BCM2712 – хоть и в ней есть что программно реализовано (это больше касается энкодера), но по производительности, она сильно уступает встроенной графике от Intel.

А теперь перейдём к вопросу – если ли этому всему, какая-то альтернатива? Да, есть. Если посмотреть, что есть на базе ARM, то более производительным будет Radxa Orion O6, который выступил себя неудачно и многих разочаровал и также есть SBC на чипах Nvidia, но то отдельная категория SBC (и более дорогая).

А со стороны Intel есть Intel N100 и его собратья. Также есть возможность взять более мощные платформы, но за больше деньги – я говорю про полноценные платформы, такие LGA1700 и AM4, которые до сих пор, остаются неплохими вариантами (также имеют возможность апгрейда, если был куплен более младший процессор).

Также, AMD64 выигрывает за счёт большего комфорта как при установке ОС, настройки системы в UEFI и большего разнообразия софта (в этих планах, ARM64 до сих пор отстаёт, но не так, как раньше). Как видим, хоть ARM SBC и могут заменить старые системы на очень слабых процессорах, но в некоторых отношениях, пока, безнадёжно отстают – в основном, это комфорт использования системы, большее удобства при установке системы и больше уникального софта, которого нет на ARM64 и отстают  ARM64 по производительности от более производительных AMD64 систем. 

И под конец, немного добавлю мнения про 2 SBC - Raspberry Pi 5 и Orange Pi 5. Если Raspberry Pi 5  с точки зрения софта всё хорошо, но в то же время, с аппаратной не так всё хорошо - нет нужных на сегодня интерфейсов и придётся закупать HAT, чтобы это компенсировать, то Orange Pi 5 больше хорош с железной точки зрения, но софт там надо дорабатывать. Как по мне - выбор каждого, кому что нужно и предпочтения, кому что нравиться.