Вы, наверное, только вывод читали? Я же в начале уточнил:
Процессор Freescale i.MX6Q основан на ядре Cortex-A9, т.е. не самый свежий, но Calxeda основана на том же ядре, да и ничего другого я попросту не нашёл. Кроме того у меня был обширный опыт ковыряния с предыдущей серией i.MX51 на китайских планшетах. Изучив работу Cortex-A9 и приняв на веру то, что A15 на той же частоте будет на 40% быстрее, можно грубо экстраполировать результаты на гипотетическую систему с Cortex-A15 на большей частоте.
вы явно что-то перепутали в настройках. Allwinner A10 ARM Cortex-A8 1.08GHz при использовании neon оптимизаций в OpenSSL выдает 33498.80k. linux-sunxi.org/Benchmarks#Results_3 A10 не может быть быстрее чем i.MX6Q.
Пересобирайте систему с нормальными флагами (выше уже сказали, плюс, можно глянуть выше по ссылочке, я там везде указывал как собирал).
Для корректного сравнения нужно брать одинаковые версии OpenSSL и gcc — они у нас разные. Кроме того вы пишите, то у вас оптимизации под neon, и в тоже время используете такие же флаги, что и я
А там SATA есть? Прелесть i.MX6Q в том, что на нём даже шина PCI-E x1! — т.е. при желании на базе него можно вполне соорудить что-то серьёзное.
Интересно, почему до сих пор никто не наладил выпуск микро-серверных платформ, те же китайцы?
К сожалению не оставил ссылку, но точно видел у них в документации, возможность создания процессора «под заказчика» и список блоков-«кирпичиков» из которых можно построить свою SoC. Главное большую партию заказать.
Пока хостеры не особо заморачиваются с подсчётом энергии. Вот, например, УкрТелеКом: До 2-х юнитов, до 650Вт уже включено в тариф. Понятно, что при таких условиях никто не будет оптимизировать размеры и тепловыделение. Как только повесят на каждый сервер счётчик электроэнергии, процесс пойдёт гораздо быстрее. Мне недавно штатовский хостер предложил заменить арендованные сервера (очень старые) с P4-1.7GHz на атомные.
Совершенно верно, что сравнение не корректно. Собственно я об этом сделал ремарку. Просто никакого более подходящего и доступного ARM-ядра я не нашёл. Да и задачи тестирования ставились другие — можно ли заменить в моих текущих применениях Atom-ные решения на ARM-омовские, если бы они были доступны. Чуть корректней было бы брать «серверный» Atom, например S1260, на нём хотя бы нет видеоядра на кристалле.
По приведённой ссылке на ODROID-PC Full Package процессор 2х-ядерный на 1.2GHz, а на других вариантах нет SATA.
На моей плате SSD-винт выдаёт всего 128МБ/с — но этого уже достаточно для тестирования гигабитных скоростей, в отличие от SD-карт. Кроме того система гораздо отзывчивей, и позволила обойтись без кросс-компиляции — да, Gentoo собиралась из исходников на этой же плате!
61625.69k — видать не обманули ARM-ы, обещая 40%-ый прирост по сравнению с A9, потому что если взять мой результат 26757.80k, да помножить на коэффициент по частоте (1700/996=1.71), а потом ещё на обещанные 40%, то мы получим 64058.17к, что очень близко к вашему результату!
Дельное замечание. Действительно, с -march=native gcc определяет -march=armv7-a (что нормально) и -mcpu=[default]. Какое у него default мы не знаем, поэтому явно дописал -mcpu=cortex-a9 и пересобрал OpenSSL. Но разницы в скорости нет, ну точнее в пределах погрешности — где чуть больше, где чуть меньше.
Я так подозреваю, что в моих тестах floating point, если и используется, то только в статистике, там точно векторных вычисление не нужно.
А так она определяется правильно:
Clang — это интересный вопрос, обязательно проверю.
AES — нет, аппаратное точно не используется, потому что для активации во-первых, нужно в командной строке передавать ядру опцию «caam», и во-вторых, когда работает ускорение, то user time в openssl speed или ноль или около того.
Тесты Arndale board я не видел, хотелось бы глянуть. Но мысль такая, что даже если аппаратное ускорение фантастически быстрое, то только в один поток. Когда на сервере висит пару тысяч подключение, оно должно захлебнуться. На моём i.MX6Q есть аппаратное кодирование видео в VP8 (!!!), но опять же — в один поток. Если запустить несколько, то они скорее всего будут просто ждать пока освободится аппаратный кодировщик. Поэтому реализация Intel-ом набора инструкций AES-NI выглядит гораздо элегантней.
На Xeon E3-1220 в 4 потока, без ускорения у меня такие циферки
без ускорения: aes-256 cbc 354709.61k 375930.92k 380990.12k 383823.87k 384417.79k
с ускорением: 1748189.47k 1839156.80k 1856688.81k 1865963.52k 1867699.54k — почти в 5 раз быстрее.
На ODROID-е 2х-ядерный Cortex-A9 и 100-мегабитный Ethernet (на Sabre 4х-ядерный и «почти» гигабит). Ну и ODROID дороже.
ARNDALE — очень интересная плата, к сожалению я её поздно заметил.
В пользу Freescale i.MX6Q я ещё упоминал свой опыт (довольно позитивный) с предыдущей серией i.MX51, а ещё забыл написать, что мне очень нравится открытость платформы — множество репозиториев с исходниками Linux-а и Android-а, огромное комьюнити, и даже тех. поддержка — бесплатная и относительно вменяемая.
Клавиатура Apple A1243 — для меня удобнее нет. Не смотря на то, что у меня PC, установил Boot Camp и все мультимедийные клавишы работают — очень удобно.
По тактильным ощущениям — превосходно, но как вы боретесь с отсутствием Ins-а, микроскопическим Enter-ом и тильдой в необычном месте?
Бывший глава THQ отметил, что сотрудники 4A Games были вынуждены смириться не только с ограниченными ресурсами, но и с ужасными условиями работы. «Сотрудники 4A сидели за маленькими столиками на складных стульях практически плечом к плечу. Все это больше напоминало кафе в какой-нибудь школе, а не студию по разработке игр», — заявил Джейсон. Он рассказал, что, помимо тесноты, 4A Games приходилось мириться с постоянными перебоями с электричеством — спасали лишь портативные генераторы, которые сотрудники приносили из дома. Рабин хотел отправить разработчикам нормальные офисные стулья, но сделать это не удалось. Во-первых, они просто не поместились бы в офисе. Во-вторых, их пришлось бы везти контрабандой через Польшу, так как в Киеве такая мебель не продается.
А игра ведь получилась отличная. А если бы у них были другие кресла, был бы такой же результат? :)
Меня в большом кожаном кресле «для руководителя» постоянно тянуло на сон. И вот почитав вышеупомянутую новость, озаботился выбором нового устройства для фиксации программиста в удобной позе. Купил такое
И после недели использования могу сказать, что это то что надо! Самое главное, как в рекламе памперсов, — программист чувствует себя сухо и комфортно! Оно легче, мобильней — удобней подкатываться к соседним столам. Правда выше комментаторы пишут, что сетка растянется, это огорчает, но посмотрим.
BIOS на видеокартах — это обычно Serial EEPROM, который отображается в адресное пространство процессора страницами со специальными атрибутами. Это при условии, что пользователь не установил в своих настройках BIOS-а материнской платы галочку "Video ROM BIOS Shadow", тогда всё шоколадно.
Доступ к EEPROM памяти, находящейся на другой плате, через несколько последовательных шин — довольно небыстрая процедура, ширина — 8 бит (да, да — те самые байты), читать надо подряд, иначе процессор обидится, и придётся чуток подождать.
Таким образом, вы должны гордится автором того кусочка, так как он сделал минимально возможный размер кода, исключив функцию определения типа страницы памяти и не дублируя приведённый кусочек кода (он же там больше) под разные сценарии.
Если всё же нужно прочитать двойное слово и аппаратура умеет это делать, то программная эмуляция действий аппаратуры будет заведомо медленнее самой аппаратуры.
В таком случае не было многотомных Optimization Guide-ов, лекций и семинаров посвящённых данному вопросу, так как следую вашей логике — раз аппаратура умеет сделать что-то одной инструкцией, то нечего пытаться заменить это несколькими?
Кроме того, почитайте обсуждение — все фокусируются на быстродействии, а не на размере. В реальных проектах компиляция идёт не с -Os, а с -O2 — ведь большой размер — это даже престижно.
А у вас размер — это самоцель какая-то? На PC расширить память — не проблема, увеличить производительность — да. Для маленьких/встраиваемых устройств, там где размер имеет значение, компилируется с -Os (например в XCode под iOS Release).
По производительности — скажите, где у вас профайлер показывает затыки, и я попробую пооптимизировать. Но опять таки, под какой процессор, какую память?
Как я писал выше, в асме очень важен контекст. В данном случае у меня есть предположение, что где-то выше, эти данные были записаны как байты, а значит читать их двойным словом будет медленно. Не нравятся кэшам такие «оптимизации».
С компилятором GCC: (Gentoo 4.7.3 p1.0, pie-0.5.5) 4.7.3" код такой же, что и у jcmvbkbc.
И ещё интересная инфа, родной маковский nasm (NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on Feb 6 2013) кодирует push imm8 (без префикса размера) в 5 байт, также как если указать DWORD, а вот с BYTE — в два байта.
По производительности — второй пример был из планировщика ehci_select_hs_interrupt_list — там же не вызывается сброс контроллера каждый раз?
Трудоёмкость — да, очень хочу убедить, так как шишек много. Опять таки, это был первый попавшийся на глаза пример. Если очень интересно — можно ещё найти места, где используются лишние копирования (потому что человеку не под силу держать в голове текущий контекст программы), где инструкции идут не в самом благоприятном порядке — это всё макросами не исправишь (movi — оперативненько!)
И насчёт «размер результата будет в разы больше» это вы погорячились. Я тоже так думал, ровно до тех пор, пока компилятор не стал генерить сравнимый (а зачастую и более короткий и быстрый код). Учитывая разницу во времени на получение этого результата, я крепко призадумался. Потом переписывал только маленькие критические кусочки, потом интринсики.
Ну сколько вы выиграете на всём ядре, килобайт? может быть два? А производительность приносите в жертву. Этот кусочек не единственный, вот в планировщике, подряд
push 5
pop ecx
push 1
pop ebx
push sizeof.ehci_static_ep
pop edx
а конструкции вида
push imm
pop reg32
call proc
вообще сериализация. Ну и не понятно тогда, почему же, если вы оптимизируете под размер, то всё равно много где используется нормальная загрузка значения, как
mov ecx, 4
Где же однообразие кода и подхода?
Да вы и сами, наверняка, знаете, что не всё с кодом оптимально, но из-за ассемблера, изменения становятся вся более трудоёмкими, поэтому начинает преобладать принцип: «работает? — не лезь!»
А Си-шый код так легко перекомпилировать, и новым компилятором, и под новый процессор…
Сейчас использую ассемблер только для PIC-микроконтроллеров — вот там он востребован, так как счёт действительно идёт на байты.
Вы молодцы, ваш проект — замечательный пример программирования на ассемблере, школьникам и студентам для обучения вообще бомба. Но для реальных задач, ИМХО, Сизифов труд.
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
Интересно, почему до сих пор никто не наладил выпуск микро-серверных платформ, те же китайцы?
К сожалению не оставил ссылку, но точно видел у них в документации, возможность создания процессора «под заказчика» и список блоков-«кирпичиков» из которых можно построить свою SoC. Главное большую партию заказать.
На моей плате SSD-винт выдаёт всего 128МБ/с — но этого уже достаточно для тестирования гигабитных скоростей, в отличие от SD-карт. Кроме того система гораздо отзывчивей, и позволила обойтись без кросс-компиляции — да, Gentoo собиралась из исходников на этой же плате!
А так она определяется правильно:
Clang — это интересный вопрос, обязательно проверю.
AES — нет, аппаратное точно не используется, потому что для активации во-первых, нужно в командной строке передавать ядру опцию «caam», и во-вторых, когда работает ускорение, то user time в openssl speed или ноль или около того.
Тесты Arndale board я не видел, хотелось бы глянуть. Но мысль такая, что даже если аппаратное ускорение фантастически быстрое, то только в один поток. Когда на сервере висит пару тысяч подключение, оно должно захлебнуться. На моём i.MX6Q есть аппаратное кодирование видео в VP8 (!!!), но опять же — в один поток. Если запустить несколько, то они скорее всего будут просто ждать пока освободится аппаратный кодировщик. Поэтому реализация Intel-ом набора инструкций AES-NI выглядит гораздо элегантней.
На Xeon E3-1220 в 4 потока, без ускорения у меня такие циферки
без ускорения: aes-256 cbc 354709.61k 375930.92k 380990.12k 383823.87k 384417.79k
с ускорением: 1748189.47k 1839156.80k 1856688.81k 1865963.52k 1867699.54k — почти в 5 раз быстрее.
ARNDALE — очень интересная плата, к сожалению я её поздно заметил.
В пользу Freescale i.MX6Q я ещё упоминал свой опыт (довольно позитивный) с предыдущей серией i.MX51, а ещё забыл написать, что мне очень нравится открытость платформы — множество репозиториев с исходниками Linux-а и Android-а, огромное комьюнити, и даже тех. поддержка — бесплатная и относительно вменяемая.
А игра ведь получилась отличная. А если бы у них были другие кресла, был бы такой же результат? :)
Меня в большом кожаном кресле «для руководителя» постоянно тянуло на сон. И вот почитав вышеупомянутую новость, озаботился выбором нового устройства для фиксации программиста в удобной позе. Купил такое
И после недели использования могу сказать, что это то что надо! Самое главное, как в рекламе памперсов, — программист чувствует себя сухо и комфортно! Оно легче, мобильней — удобней подкатываться к соседним столам. Правда выше комментаторы пишут, что сетка растянется, это огорчает, но посмотрим.
Доступ к EEPROM памяти, находящейся на другой плате, через несколько последовательных шин — довольно небыстрая процедура, ширина — 8 бит (да, да — те самые байты), читать надо подряд, иначе процессор обидится, и придётся чуток подождать.
Таким образом, вы должны гордится автором того кусочка, так как он сделал минимально возможный размер кода, исключив функцию определения типа страницы памяти и не дублируя приведённый кусочек кода (он же там больше) под разные сценарии.
По производительности — скажите, где у вас профайлер показывает затыки, и я попробую пооптимизировать. Но опять таки, под какой процессор, какую память?
С компилятором
GCC: (Gentoo 4.7.3 p1.0, pie-0.5.5) 4.7.3"код такой же, что и у jcmvbkbc.И ещё интересная инфа, родной маковский nasm (NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on Feb 6 2013) кодирует push imm8 (без префикса размера) в 5 байт, также как если указать DWORD, а вот с BYTE — в два байта.
Трудоёмкость — да, очень хочу убедить, так как шишек много. Опять таки, это был первый попавшийся на глаза пример. Если очень интересно — можно ещё найти места, где используются лишние копирования (потому что человеку не под силу держать в голове текущий контекст программы), где инструкции идут не в самом благоприятном порядке — это всё макросами не исправишь (movi — оперативненько!)
И насчёт «размер результата будет в разы больше» это вы погорячились. Я тоже так думал, ровно до тех пор, пока компилятор не стал генерить сравнимый (а зачастую и более короткий и быстрый код). Учитывая разницу во времени на получение этого результата, я крепко призадумался. Потом переписывал только маленькие критические кусочки, потом интринсики.
а конструкции вида
вообще сериализация. Ну и не понятно тогда, почему же, если вы оптимизируете под размер, то всё равно много где используется нормальная загрузка значения, какГде же однообразие кода и подхода?
Да вы и сами, наверняка, знаете, что не всё с кодом оптимально, но из-за ассемблера, изменения становятся вся более трудоёмкими, поэтому начинает преобладать принцип: «работает? — не лезь!»
А Си-шый код так легко перекомпилировать, и новым компилятором, и под новый процессор…
Сейчас использую ассемблер только для PIC-микроконтроллеров — вот там он востребован, так как счёт действительно идёт на байты.
Вы молодцы, ваш проект — замечательный пример программирования на ассемблере, школьникам и студентам для обучения вообще бомба. Но для реальных задач, ИМХО, Сизифов труд.