Быстрое удаление пробелов из строк на процессорах ARM — альтернативный анализ

[advbg]

Перевод ответа от Мартина Кръстева: Да, хорошо было бы. Но есть одно но: естество теста таково, что компилятору особенно нечего оптимизировать, кроме упорядочивания инструкций оптимальным образом (scheduler). Но хорошо бы действительно посмотреть на g++ по-новее. У меня самого не хватило времени обеспечить наличие g++ 6.x на разных платформах, в то время как 4.х и 5.х уже были там.

[dorne]

Я взял на себя смелость изменить первоначальную процедуру обрезки SSSE3 Даниэля — на самом деле, я использовал свою версию для теста. Причина? Я не могу просто так взять 2 ^ 16 * 2 ^ 4 = 1 Мбайт таблицы поиска в моем коде — это был бы большой пожиратель кеша для любых сценариев, где мы не просто обрезаем потоки ascii, но вызов подпрограммы облегчает другую работу.

Если не использовать кеш на полную, то всё, что на самаом деле будет измеряться, — это скорость памяти. Так получилось исторически, что в армах и x86 память одинаково медленная. Так получилось, что тактовая частота у х86 больше. Поэтому, больше циклов расходуется впустую в ожидании ответа от памяти. Отсюда и результаты измерния в «тактах ЦП на символ».

[khim]

Но и использовать мегабайт кеша на весьма и весьма вспомогательную задачу — очень расточительно. Однако есть большая проблема: в оригинальной статье только версия для SSSE3 использует эту гигантскую таблицу! SSE4.2 и AVX обходятся без неё!

А с учётом того, что процессоры без поддержки SSE4.2 пропали из продажи примерно тогда же, когда в продаже только появились ARMv8 процессоры… таки странное сравнение вышло, да.

Хотя и небесполезное: из него мы можем видеть что архитектурно ARM отстаёт от x86 вдвое, хотя практически — вшестеро.

P.S. И, несмотря на это, у меня есть ощущение, что ARM вытеснит-таки x86 со временем. Просто потому что x86 архитектуру «вылизывать» уже, в общем-то, некуда — а стоит она куда дороже. Классика подрывных инноваций. Но ещё лет 10-20, я думаю, у старичка есть…

[dorne]

Всё зависит от задачи. Вылизывать ARM до уровня x86 стоит денег и времени. Когда это будет сделано, то и цены будут схожие.

[amarao]

Разница в том, что x86 вылизывают две компании, а арм — куча конкурирующих. Не факт, что вылизывание будет лучше, но что будет дешевле, чем в случае олигополии — факт.

[khim]

Собственно до относительно недавнего времени ARM вообще не играл на поле «быстрых» CPU. Размер ядра (и, соответственно, цена) — было самой важной ценностью. После буквально десятилетий развития Intel'а на поле «быстрее, выше, сильнее» и ARM'а на поле «дешевле, эффективнее» тренд развернулся меньше 10 лет назад (догадайтесь из-за чего, или, вернее, из-за кого). И тот факт, что разница между Inetl и ARM'ом уже всего лишь двукратная — плохой знак для Intel'а…

[notorca]

Вот способ по скорости сопоставимый с версией использующей таблицу на 1Mb но без таблицы. Не очень простой для понимания, но быстрый и без дополнительной памяти

[mrhru]

В коде, в начале статьи, ошибка. Функция не удаляет последний пробел если он последний во входном массиве. В результате в статье производится сравнение быстродействия процессоров на каком-то алгоритме, но не на декларируемом. ;)

[advbg]

Общий ответ от Мартина Кръстева:
Тест идет полностью из L1, который всега работает на частоте процессора, так что частота процессора не играет роли в этом тесте.
В оригинале Даниела поищите despace_mask16 — это таблица.

Апропо, идея данного теста быть микро- и макро-архитектурным — т.е. какие инструкции сколько работы успевают сделать — не случайно он не должен зависеть от доступа к памяти (вне L1)
А задуман он именно так, потому что если помните, Даниел жаловался что не хватает одной важной инструкции в ARM (которая на нем заменяется двумя), и поэтому он не мог написать быстрый пруннер.
Я считаю, что скалярный тест и векторный тест показывают довольно ясно, что архитектурно ARM справляется лучше — больше работы за меньше инструкций. И это видно по результатам лучшего соотношения работа/такт в скалярной версии, но в SIMD версии ARM отстает в два раза из-за плохой микроархитекрурной реализации.
(т.е. там инструкций меньше, но они выполняются за больше тактов)
А по теме 'а практически — в шестеро!' — посмотрите следующую статья Даниела, где он сам приходит к выводу, что ARM ~3 раза медленнее (после всех правок и советов его читателей).

Спасибо)

[advbg]

Небольшое дополнение без перевода:
github.com/blu/ascii_pruner/blob/master/README.md

[tyomitch]

И где дополнение? Это та же ссылка, что и на оригинал статьи.