Заметки из мира IT

В стиле минимализм

Экспансия процессоров на архитектуре ARM продолжается, и все больше и больше производителей заявляют о своих планах выйти на этот рынок. А рынок этот очень...
http://dynamic.versusit.ru/Files/2013/ea352141-1ddb-4f31-ace2-ea2c63c7d02e.png

Экспансия процессоров на архитектуре ARM продолжается, и все больше и больше производителей заявляют о своих планах выйти на этот рынок. А рынок этот очень интересный и перспективный. Естественно, что все производители понимают, что пытаться создавать решения на базе x86 абсурдно т.к. с такими гигантами как AMD и Intel будет тягаться очень тяжело, а вот наработки в области архитектуры ARM есть у многих.

Хотя Intel много раз пыталась вывести на мобильный рынок процессоры на базе x86, но у них ничего из этого не получилось. А ARM-процессоры, успели за это время перейти в начале с телефонов на планшеты, а потом стали понемногу захватывать рынок (пока)дешевых ноутбуков и низовой сегмент серверного рынка. Разумеется пока рассматривать процессоры ARM как конкурент взрослым тяжеловесным решениям типа Xeon слишком рано, однако Xeon’ы нужны не всем и как показала практика есть большой востребованностью пользуются сервера со сверхинким энергопотреблением типа Intel Atom. А вот тут-то как раз ARM уже можно рассматривать как реального конкурента.

Теперь постараемся провести сравнение ARM и x86. В силу того, что на данный момент выбор оказался ограничен, пришлось взять плату SABRE Lite с уже стареньким процессором ядре Cortex-A9. Процессор на ядре A15 на той же частоте будет на 40% быстрее, поэтому можно грубо экстраполировать результаты на гипотетическую систему с Cortex-A15 на большей частоте.

Процессор Atom в тестировании будет представлен двумя моделями:
— D525 на платформе SuperMicro SuperServer 5015A-EHF-D525 (1.8 GHz)
— Снятый с производства флагман D2700 (2.13 GHz) на плате Intel® Desktop Board D2700MUD

Две модели нужны для того, чтобы выяснить как система масштабируется по частоте. К сожалению, Intel решила, что в дешёвых десктопных процессорах технологии энергосбережения (управления питанием/частотой) ни к чему, они и так потребляют всего-ничего.




Процессор ARM (i.MX6Q) тоже будет рассмотрен в двух вариантах — 996MHz и 396MHz — это частоты, поддерживаемые в cpufreq.

http://dynamic.versusit.ru/Files/2013/0092ff5c-7b01-402d-bc33-eedc10c1ab4a.png

Софт и настройки на всех системах идентичны: Gentoo Linux 3.x, NGINX 1.4.1, OpenSSL 1.0.1e, GCC 4.8.1 (-O3 -march=native), а на ARM-е дополнительно опция генерации кода в Thumb (-mthumb). По поводу последней есть разные мнения, но конкретно на моей системе, помимо того, что код получался гарантировано меньшего размера, в большинстве тестов ещё и немного быстрее.

Тестовые системы и клиентский компьютер гигабитными портами включены в гигабитный свитч.

Понятно, что напрямую сравнивать эти системы не совсем корректно, т.к. разные архитектуры, i.MX — это самодостаточный SoC, а D2700 — классический микропроцессор, которому нужна обвязка из южного моста и прочих чипов-компаньонов. Пока ещё нет Atom-ов с такой же степенью интеграции, но процесс идёт семимильными шагами.

К плюсам Atom-ов можно отнести поддержку 64-битного режима, практическую пользу которого мы проверим в тестах.
i.MX6Q основан на ядре Cortex-A9, а значит он, в отличии от соперника, поддерживает внеочерёдное исполнение команд (out-of-order), плюс 4 честных ядра. Кроме того в нём интегрирован аппаратный криптографический движок CAAM — тоже попытаемся изучить.
По суммарным Гигагерцам практически паритет — 4.26 у Atom-а, против 3.98 у i.MX6Q.

Вместо SPEC-синтетики, проведём простые тесты подсистем, от которых зависит производительность web-сервера.

Тест 1. Сжатие gzip-ом
Допустим, сервер выступает фронт-эндом для PHP-FPM/FCGI сервера. Сжимать ответ — признак хорошего тона. Ну и трафик экономится.
Сжимается 441 файл (типичные странички с phpBB-шного форума) общим размером 42МБ.

http://dynamic.versusit.ru/Files/2013/c4cadb4b-6426-4cf0-89db-ccceec9ed596.png

i.MX-ы проигрывают, но это однопоточный тест, так что возможно не всё так плохо. Спишем на медленную подсистему памяти.

Тест 2. скорость шифрования OpenSSL алгоритмами RC4 и AES-256
Хотя A9 поддерживает аппаратное ускорение MD5, SHA-1, SHA-224, SHA-256 и ряда других алгоритмов хэширование, но стандартный OpenSSL не использует Crypto-API ядра Linux. Их можно пропатчить и научить работать вместе, что я и сделал, но гарантии, но скорость работы получилась удручающе низкой, что можно списать на не совсем корректные патчи.

http://dynamic.versusit.ru/Files/2013/4b662871-9ace-4ba7-9222-ae39e5da36b8.png

ARM-ы снова проигрывают, но не сильно. Разница в скорости между двумя и четырмя потоками на ARM ровно в два раза, что неудивительно, так как у нас четыре честных ядра. А вот на Atom-е гораздо интереснее. В х86 режиме разница составляет 1.45, т.е. Hyper-threading добавляет почти целое виртуальное ядро, а в 64-битном режиме разница всего 1.3, — эффективность от Hyper-threading ниже, но общая производительность всё равно выше. Разница в результатах между D2700 и D525 пропорциональна частоте.

http://dynamic.versusit.ru/Files/2013/f2e46f98-5424-401c-ab51-71664908f731.png

ARM наконец-то неожиданно значительно опередил Atom. Возможно это объясняется тем, что алгоритм требует гораздо больше вычислительных ресурсов, а требования к памяти ниже.

В стане Atom-ов разница в работе Hyper-threading стала ещё более выраженная. Чем оптимальнее/быстрее код, тем меньше выигрыш от виртуальных ядер. Скорее всего дело в in-order архитектуре — чем полнее один поток загружает ресурсы ядра, тем меньше останется на второй.

Тест 3. Отдача статического HTML-файла
Тут и дальше скорость указана в килобайтах в секунду, как её выдаёт ab, т. е. 20,000 kB/sec — это 20 МБ/с
/cXX показывает количество одновременных сессий (concurrency).

http://dynamic.versusit.ru/Files/2013/09f958f8-c11c-45dc-b12f-3706196e64fd.png

Очень сильно удивляет отставание i.MX-систем. Да, 100 мегабит они дают (и для моих задач этого достаточно), даже целых 500, но почему не гигабит, как Atom-ы? Несложная вроде задача, про которую говорят «как два байта переслать». Заменил патчкорд, порт, разные настройки в ядре — тоже самое. Потом порылся по профильным форумам, и вот засада — это, оказывается, аппаратный баг, который софтом не лечится.

Тест 4. Cтатический HTML-файл со сжатием

http://dynamic.versusit.ru/Files/2013/42012d2b-1055-4a44-9416-a001aec39d10.png

Atom-ы уверенно выигрывают. X32 ABI показывает небольшое преимущество.

Тест 5. Статический HTML-файл со сжатием и шифрованием RC4

http://dynamic.versusit.ru/Files/2013/803f9a11-0610-4081-ae0a-ec881d4a592a.png

Раунд снова за Atom-ами. Огромное превосходство х64 над х86. Хорошо заметен прирост в новомодном х32 ABI.

Тест 6. Статический HTML-файл со сжатием и шифрованием AES-256

http://dynamic.versusit.ru/Files/2013/370bb4a1-0cbe-4a29-aa29-c282db97e719.png

64-битные Atom-ы впереди. Совершенно необъяснимо «выстреливает» х64 система. i.MX немного опередил х86!

Тест 7. JPEG файл

http://dynamic.versusit.ru/Files/2013/12e97055-d3b2-42ab-be94-49b882ba4c73.png

Тест 8. JPEG файл с шифрованием RC4

http://dynamic.versusit.ru/Files/2013/3a13b407-de8f-4c76-b390-a0304fb8b062.png

Тест 9. JPEG файл с шифрованием AES-256

http://dynamic.versusit.ru/Files/2013/b3de2fac-7fb5-431d-a21a-ffa146229cd4.png

Тест 10. Большой файл размером 100МБ
Тут произошёл первый нокдаун — i.MX начал постоянно зависать. Потрогал крышку, очень горячая, по датчикам — 73°. Пришлось наклеить радиатор.

Оставшиеся три раунда прошли без проблем.

В принципе, их можно было и не проводить, т. к. результаты полностью совпадают с тестами JPEG-ов, которые, в свою очередь, похожи на тест со статическим HTML.

Результаты

По очкам побеждает Atom.

Но оказывается, для моих скоромных задач в виде забивания 100-мегабитного канала, вполне хватает i.MX-а на 400MHz. Ну а фронтэндом (раздающим пожатый и шифрованный HTML) ему пока не быть.

Если верить заявлениям ARM-а относительно производительности A15, в том числе и подсистемы памяти, то вероятно победителем вышел бы Cortex-A15.

admin

Яндекс.Метрика