Ознакомьтесь, пожалуйста, с научными работами, ссылки на которые приведены в статье. Нигде в них нет исходного кода, но есть описание алгоритма, достаточное для понимания. Школьник повторить не сможет, но всем заинтересованным это не мешает воспроизводить результаты и использовать идеи.
Вы взяли, и руками наоптимизировали какой-то код под e2k. Какой в итоге - непонятно. Что получилось в ассемблере в итоге - непонятно. Что пускалось на x86 - непонятно.
Понимаю Ваш обоснованный скептицизм. К сожалению, нужно быть достаточно глубоко в теме, чтобы в деталях понимать, о каких именно реализациях идёт речь в статье. В статье есть ссылки на материалы, по которым можно со всем разобраться и даже повторить результаты, но это требует больших затрат времени и сил.
Ассемблер и, тем более, исходники у нас в России никто не показывает. Можно сказать, специфика разработки СКЗИ. Но вкратце могу рассказать следующее: под x86 используются написанные руками ассемблерные реализации, зарекомендовавшие себя как самые быстрые. Они превосходят выдаваемое компиляторами где-то на 10% (это к тому, что дальше пооптимизировать вряд ли получится). Под e2k я реализовал то же самое на Си с использованием интринсиков и получил отличный результат. Пробовал на ассемблере писать, но тут я отставал от компилятора. Я считаю, что это вполне корректное сравнение уровня микроархитектуры: что в одном, что в другом случае мы берём вручную оптимизированные реализации.
Как стакан наполовину пуст и полон одновременно, так же и в этих обсуждениях нет чёткой истины. Нет, править исходники в общем случае не нужно. Да, если нужно здесь и сейчас быстро — можно дописать pragma. Да, это ошибка в компиляторе. Досадно, что она есть. Информация о ней уже доведена до МЦСТ, в новых версиях проблему обещают исправить и нам править ничего не придётся.
Я понимаю, что Вы взяли первый попавшийся код специально, чтобы продемонстрировать проблемы. Но, на мой взгляд, этот пример всё ещё не несёт никакой прикладной ценности — я запускал сортировку 100000 элементов (всего лишь 390 КБ) на Эльбрус-8С и i7-9700K. Итоговая разница времени выполнения у них 2 раза. При этом выполнение 2-4 секунды является безобразно долгим что на одном, что на другом. Если в этом месте в программе проблема, то править исходники нужно в любом случае — переписыванием алгоритма сортировки на более быстрый. Так что этот пример показывает, какой код не надо писать в реальных программах и какие проблемы могут быть у компилятора. Но он никак не показывает того, что Вы заявляете (якобы отставание в микроархитектурной скорости). Кстати, сейчас при обучении программированию всё чаще используются методы "стимулирования к написанию хорошего кода", например, системы ejudge с контролем времени выполнения. Не уложился в 1 секунду из-за медленного алгоритма или его плохой реализации (даже на x86) — получи линейкой по пальцам штраф на несколько баллов и оценку ниже. Вряд ли неоптимальные алгоритмы или реализации можно считать нормальным явлением в местах, где реально требуется производительность :)
Вообще, вся эта ветка комментариев началась с опровержения тезиса о плохой "микроархитектуре". Согласитесь, в данном контексте он опровергнут. Да, к компилятору оказалось много вопросов и претензий, но не к "микроархитектуре".
Серьёзно? И где же там такое показано?
Там дана ссылка на мою статью, в которой рассказано об эффективности реализаций ГОСТ алгоритмов симметричного шифрования на Эльбрусе. Да, речь идёт о конкретной задаче, но пока все разговоры идут только на примерах конкретных задач.
Согласен, без проверки никуда. Поэтому берём машины на базе Эльбрус-8С @ 1.2 ГГц с 1 и 4 процессорами (дальше уточнять не буду, но результат не отличается существенно). Позволю себе для начала полениться и замерить только на массиве из 100000 элементов, как предложено в статье (это около 390 КБ). Это будет полностью честный замер скорости работы предложенной функции сортировки.
Исходный код для замера, реализация Sort по ссылке выше
Массив заполнен в порядке убывания элементов, значит, количество внутренних итераций будет порядка 100000 * 100000 \ 2. Прогон занимает 4.214 с. Итого получается 4.214 * 1200000000 / 100000 / 50000 = 1.0136 — тот самый один такт.
Чтобы дождаться квадратичной сортировки при большем размере массива, нужно много терпения, так что упрощаем тест. Удаляем внешний цикл, массив заполняем по возрастанию, в конце ставим один минимальный элемент (будем вставлять его на правильную позицию внутренним циклом while). Ставим количество элементов 200000000 (760 МБ) и запускаем. Отрабатывает за 0.214 с, то есть 1.284 такта на одну итерацию.
Для пытливых читателей пересчитаем показатель IPC: не меньше 7 полезных инструкций на один такт.
А точно все полезны?
alc — продвинуть счётчик цикла
ct — передача управления, здесь же скрыта ещё одна булева операция (&&)
staaw — 2 записи значений в память
movaw — пересылка значения из буфера APB в регистр
cmplesb — сравнение
Насчёт остальных надо думать:
abn и abp — продвинуть базу вращения числовых и предикатных регистров, соответственно — позволяет наслаивать итерации друг на друга
И ещё скрыты инструкции работы с APB, обеспечивающие подкачку данных.
Не могу не заметить, что разговор о производительности на примере сортировки вставками всё ещё оторван от реальности: если это будет узкое место, то, наверное, начать стоит с выбора другого алгоритма. Но раз уж заговорили о нём, то предлагаю не останавливаться на достигнутом.
Очень похоже, что Вы правильно определили, что "компилятор ожидает, что вложенный цикл будет коротким". Это ошибка с его стороны, которая лечится достаточно просто, хоть и затрагивает мелкую модификацию исходника: перед циклом while следует добавить #pragma loop count(1000).
Дальше можно заметить, что в программе все обращения в память соблюдают выравнивание. В этом случае следует добавить опцию компиляции -ffast (да, для Эльбруса это такой же важный шаг, как просто компиляция с включением оптимизаций). Посмотрим на результат:
В итоге вышел всего лишь один такт и даже успешно сработал механизм подкачки данных. Кстати, @alexanius давал в своей статье ссылки на ситуации, когда показано "микроархитектурное превосходство" Эльбруса, но в этой статье такая информация была проигнорирована.
Зачем же так пренебрежительно? Вам говорят, что о Вас хорошо отзываются, а Вы — "это молодёжь из соседнего отдела, которым некоторые адепты Эльбруса задурили голову, а в силу их очень скромных знаний, эту лапшу с ушей они ещё не сняли". По информации из открытых источников, между Вами разница в возрасте порядка 8 лет. Если бы Вам было 28, а оппоненту 20, — ещё можно попытаться как-то понять...
Вместо фантазий о важности и сложности лучше бы пошли и поигрались. Ломается инлайнинг буквально от любого чиха https://godbolt.org/z/dao3a7qjj
Фантазий у автора статьи точно нет — он занимается разработкой компилятора и видит тысячи примеров, но это лирическое отступление. По делу: а что показывает Ваш пример? Очевидно, невозможно подставить printf в тело цикла. Только настоящий вопрос здесь: зачем вообще это делать, какой выигрыш будет от подстановки такой функции? По сравнению с одной инструкцией умножения и несколькими тактами на тело без учёта printf сам printf займёт всё время исполнения. Насколько я знаю, замена printf на, скажем, fwrite значительно ускорит исполнение. Можно пойти дальше и заменить на write — ещё быстрее. Но цикл, в теле которого в любом случае есть системный вызов, — это точно тот горячий цикл, в котором важна подстановка функции?
1) В каком месте статьи Вы видите, что @alexanius выразился, что "автор манипулирует цифрами, пересчитывая скорость на такты, чтобы заявить о какой-то сравнимой скорости с интелами?"
2) Где, собственно, манипуляции в исходной статье? Приглашаю Вас ознакомиться с текстом. Там есть значения абсолютной скорости - по ним Эльбрусы сравнимы и в одной ситуации даже превосходят все остальные процессоры. Там же есть данные по тактам на байт (Эльбрусы уверенно превосходят), что здесь подчёркивается как качество микроархитектуры Эльбрусов.
Большое спасибо за интерес и статью, отличный результат! Вы прямо-таки исполнили моё тайное желание: после появления статьи захотелось посмотреть, как будет выглядеть реализация шифрования на подобном DSP и какой результат получится. И тут Вы - не в бровь, а прямо в глаз!
По поводу скорости: на мой взгляд, 17 тактов на байт при последовательной обработке - замечательный результат. Вообще, меньше 20 уже очень хорошо (современные Intel и AMD тратят около 22 в тех же условиях).
Большая проблема приведённой в статье таблицы — это перечисление характеристик конкретных выпущенных процессоров. Вы берёте конкретные модели и обобщаете их опыт на весь подход. Данные образцы отстают, но является ли это свойством архитектуры на базе VLIW? А как же вопрос затраченных на разработку ресурсов. Неудача гиганта уровня Intel заставляет задуматься, но весьма вероятно, что из-за отсутствия быстрого успеха они потом вкладывали в IA-64 меньше, чем в x86. А исходная неудача IA-64 — это, естественно, сумма факторов, недостатки VLIW в которой сыграли не в первую очередь.
Тем не менее, примеры из реального кода были бы намного более интересны и содержательны (естественно, на горячих циклах). Можно справедливо допустить, что появление других операций приведёт к изменению поведения компилятора и отказу от подстановки функции. Но это приведёт и к увеличению наполненности ШК. Так что возникает вопрос: сохранится ли отставание в более сложном примере? Уверен, оно наоборот сократится.
К тому же, Эльбрус невозможно рассматривать в отрыве от конкретного компилятора. Не скажу, что это хорошо, это создаёт определённые неудобства разработчикам. Тем не менее, есть факт: при использовании различных версий компилятора ощущаются существенные различия. От версии 1.23 до 1.26 наблюдается улучшение производительности, в частности, от подстановок функций, которые раньше не происходили. Насчёт более ранних версий не знаю, не использовал, может быть, там не было видимого роста.
Потом следует отметить, что ваш пример показывает, с какими проблемами можно столкнуться из-за отсутствия предсказателя переходов. Точно так же можно привести альтернативный пример: условный переход в цикле. Традиционно компиляторы под x86-64 генерируют код с переходом. Ручное переписывание с заменой условного исполнения на арифметические операции позволяет добиться кратного ускорения. С другой стороны, из-за предикатного исполнения на Эльбрусе такой проблемы нет. И ни один из этих примеров не показывает явного преимущества одной архитектуры над другой.
Кажется, появление предсказателя переходов решит определённый пласт проблем. Почему его довольно давно обещают, но ещё не сделали — это не выглядит как технический вопрос. Но отсутствие предсказателя — это недостаток строго текущей версии архитектуры, а не идеи в целом. Боюсь, заявлять тупиковость развития на основании этого — слишком громко.
Действительно, не понимаю, как можно сравнивать inlining и VLIW. Подстановка функции - это техника оптимизации, работает под любую архитектуру, в том числе VLIW, в том числе Эльбрус.
И этот вопрос я адресую именно вам, потому что автор верно понял мой первый вопрос и ответил на него, а подмена понятий началась у вас.
Боюсь, вы были невнимательны при чтении статьи. Речь о том, сколько будет выполняться тело цикла, если не удалось подставить функцию (например, она в другом модуле компиляции). Или вы считаете Эльбрус настолько отстающим, что у него одно целочисленное сложение занимает 17 тактов?
Вопрос про цикл с вызовом функции. Вы проверяли, какой получается результат? 17 тактов в случае Эльбруса кажется реалистичным результатом. Но вот один такт на других архитектурах - не верится совсем.
Я понимаю, что вы нацелились на самую широкую аудиторию, но заявляете техническое рассмотрение вопроса, а значит нужно больше деталей. Если это скучные детали, можно скрыть их под спойлер, большинство сможет пропустить.
Всё ещё сильно зависит от режима шифрования. При прикладном примении (ipsec, tls) лучшим вариантом по скорости будет MGM, но тогда надо все значения скорости поделить на 2 (особенность режима). Если брать другие режимы с аутентификацией, то там даже невозможно организовать параллельную обработку блоков, так что скорость упадёт совсем сильно.
Было бы интересно подробнее узнать про wave формы, как узнать, где "тормозит конвейер" и прочие детали. Хотя бы пару ссылок.
Листинги ассемблера, наверное, стоит убрать под спойлер, а то занимают основную часть статьи.
Ну и хотелось бы, конечно, больше информации про то, какую реализацию брали и способ замера. Без подготовки читать ассемблер невозможно, а вычленять из него идею — и того хуже. И почему именно разбивка 6+4 на ALU/SIMD? Кажется, что при наличии 32 регистров NEON можно уместить обработку больше, чем 4 блоков, что должно положительно сказаться на скорости. Про замер интересует хотя бы режим шифрования (ECB?), наличие работы с памятью или шифрование на месте в цикле...
В существование чего именно вы не верите? Описание реализаций достаточно подробное, можете самостоятельно повторить результаты и даже, вполне возможно, превзойти их. Стандарты на эти шифры достаточно свежие, идеи, лежащие в основе реализаций, тоже не назовёшь слишком старыми, так что аналогия с абстрактным тестом 2003 года мне не ясна. Если нет уверенности в существовании процессоров, то вынужден огорчить: они существуют и к ним легко можно получить удалённый доступ. Кроме, пожалуй, инженерных образцов последнего поколения, они пока не выставлены в общий доступ.
Что именно вы хотите этим сказать? Если пересчитать данные из статьи, то выходит, что core i7-9700K показывает больше 25 Гбит/с на всех ядрах, а Эльбрус-16С может выдать порядка 56 Гбит/с.
В статье как раз есть ссылка на руководство, в нём уже много информации (это как раз в мае прошлого года случилось). Больше открытой информации пока не было, но и имеющейся достаточно для хорошего старта.
По поводу приобретения лично пока не интересовался, но у физических лиц уже достоверно есть машины в личном пользовании, в чате могут проконсультировать.
Ознакомьтесь, пожалуйста, с научными работами, ссылки на которые приведены в статье. Нигде в них нет исходного кода, но есть описание алгоритма, достаточное для понимания. Школьник повторить не сможет, но всем заинтересованным это не мешает воспроизводить результаты и использовать идеи.
Понимаю Ваш обоснованный скептицизм. К сожалению, нужно быть достаточно глубоко в теме, чтобы в деталях понимать, о каких именно реализациях идёт речь в статье. В статье есть ссылки на материалы, по которым можно со всем разобраться и даже повторить результаты, но это требует больших затрат времени и сил.
Ассемблер и, тем более, исходники у нас в России никто не показывает. Можно сказать, специфика разработки СКЗИ. Но вкратце могу рассказать следующее: под x86 используются написанные руками ассемблерные реализации, зарекомендовавшие себя как самые быстрые. Они превосходят выдаваемое компиляторами где-то на 10% (это к тому, что дальше пооптимизировать вряд ли получится). Под e2k я реализовал то же самое на Си с использованием интринсиков и получил отличный результат. Пробовал на ассемблере писать, но тут я отставал от компилятора. Я считаю, что это вполне корректное сравнение уровня микроархитектуры: что в одном, что в другом случае мы берём вручную оптимизированные реализации.
Как стакан наполовину пуст и полон одновременно, так же и в этих обсуждениях нет чёткой истины. Нет, править исходники в общем случае не нужно. Да, если нужно здесь и сейчас быстро — можно дописать pragma. Да, это ошибка в компиляторе. Досадно, что она есть. Информация о ней уже доведена до МЦСТ, в новых версиях проблему обещают исправить и нам править ничего не придётся.
Я понимаю, что Вы взяли первый попавшийся код специально, чтобы продемонстрировать проблемы. Но, на мой взгляд, этот пример всё ещё не несёт никакой прикладной ценности — я запускал сортировку 100000 элементов (всего лишь 390 КБ) на Эльбрус-8С и i7-9700K. Итоговая разница времени выполнения у них 2 раза. При этом выполнение 2-4 секунды является безобразно долгим что на одном, что на другом. Если в этом месте в программе проблема, то править исходники нужно в любом случае — переписыванием алгоритма сортировки на более быстрый. Так что этот пример показывает, какой код не надо писать в реальных программах и какие проблемы могут быть у компилятора. Но он никак не показывает того, что Вы заявляете (якобы отставание в микроархитектурной скорости). Кстати, сейчас при обучении программированию всё чаще используются методы "стимулирования к написанию хорошего кода", например, системы ejudge с контролем времени выполнения. Не уложился в 1 секунду из-за медленного алгоритма или его плохой реализации (даже на x86) — получи
линейкой по пальцамштраф на несколько баллов и оценку ниже. Вряд ли неоптимальные алгоритмы или реализации можно считать нормальным явлением в местах, где реально требуется производительность :)Вообще, вся эта ветка комментариев началась с опровержения тезиса о плохой "микроархитектуре". Согласитесь, в данном контексте он опровергнут. Да, к компилятору оказалось много вопросов и претензий, но не к "микроархитектуре".
Там дана ссылка на мою статью, в которой рассказано об эффективности реализаций ГОСТ алгоритмов симметричного шифрования на Эльбрусе. Да, речь идёт о конкретной задаче, но пока все разговоры идут только на примерах конкретных задач.
Согласен, без проверки никуда. Поэтому берём машины на базе Эльбрус-8С @ 1.2 ГГц с 1 и 4 процессорами (дальше уточнять не буду, но результат не отличается существенно). Позволю себе для начала полениться и замерить только на массиве из 100000 элементов, как предложено в статье (это около 390 КБ). Это будет полностью честный замер скорости работы предложенной функции сортировки.
Исходный код для замера, реализация Sort по ссылке выше
Массив заполнен в порядке убывания элементов, значит, количество внутренних итераций будет порядка 100000 * 100000 \ 2. Прогон занимает 4.214 с. Итого получается 4.214 * 1200000000 / 100000 / 50000 = 1.0136 — тот самый один такт.
Чтобы дождаться квадратичной сортировки при большем размере массива, нужно много терпения, так что упрощаем тест. Удаляем внешний цикл, массив заполняем по возрастанию, в конце ставим один минимальный элемент (будем вставлять его на правильную позицию внутренним циклом while). Ставим количество элементов 200000000 (760 МБ) и запускаем. Отрабатывает за 0.214 с, то есть 1.284 такта на одну итерацию.
Для пытливых читателей пересчитаем показатель IPC: не меньше 7 полезных инструкций на один такт.
А точно все полезны?
alc — продвинуть счётчик цикла
ct — передача управления, здесь же скрыта ещё одна булева операция (&&)
staaw — 2 записи значений в память
movaw — пересылка значения из буфера APB в регистр
cmplesb — сравнение
Насчёт остальных надо думать:
abn и abp — продвинуть базу вращения числовых и предикатных регистров, соответственно — позволяет наслаивать итерации друг на друга
И ещё скрыты инструкции работы с APB, обеспечивающие подкачку данных.
Не могу не заметить, что разговор о производительности на примере сортировки вставками всё ещё оторван от реальности: если это будет узкое место, то, наверное, начать стоит с выбора другого алгоритма. Но раз уж заговорили о нём, то предлагаю не останавливаться на достигнутом.
Очень похоже, что Вы правильно определили, что "компилятор ожидает, что вложенный цикл будет коротким". Это ошибка с его стороны, которая лечится достаточно просто, хоть и затрагивает мелкую модификацию исходника: перед циклом while следует добавить
#pragma loop count(1000).Дальше можно заметить, что в программе все обращения в память соблюдают выравнивание. В этом случае следует добавить опцию компиляции -ffast (да, для Эльбруса это такой же важный шаг, как просто компиляция с включением оптимизаций). Посмотрим на результат:
В итоге вышел всего лишь один такт и даже успешно сработал механизм подкачки данных. Кстати, @alexanius давал в своей статье ссылки на ситуации, когда показано "микроархитектурное превосходство" Эльбруса, но в этой статье такая информация была проигнорирована.
Зачем же так пренебрежительно? Вам говорят, что о Вас хорошо отзываются, а Вы — "это молодёжь из соседнего отдела, которым некоторые адепты Эльбруса задурили голову, а в силу их очень скромных знаний, эту лапшу с ушей они ещё не сняли". По информации из открытых источников, между Вами разница в возрасте порядка 8 лет. Если бы Вам было 28, а оппоненту 20, — ещё можно попытаться как-то понять...
Фантазий у автора статьи точно нет — он занимается разработкой компилятора и видит тысячи примеров, но это лирическое отступление. По делу: а что показывает Ваш пример? Очевидно, невозможно подставить printf в тело цикла. Только настоящий вопрос здесь: зачем вообще это делать, какой выигрыш будет от подстановки такой функции? По сравнению с одной инструкцией умножения и несколькими тактами на тело без учёта printf сам printf займёт всё время исполнения. Насколько я знаю, замена printf на, скажем, fwrite значительно ускорит исполнение. Можно пойти дальше и заменить на write — ещё быстрее. Но цикл, в теле которого в любом случае есть системный вызов, — это точно тот горячий цикл, в котором важна подстановка функции?
Постойте, 2 вопроса по последнему абзацу:
1) В каком месте статьи Вы видите, что @alexanius выразился, что "автор манипулирует цифрами, пересчитывая скорость на такты, чтобы заявить о какой-то сравнимой скорости с интелами?"
2) Где, собственно, манипуляции в исходной статье? Приглашаю Вас ознакомиться с текстом. Там есть значения абсолютной скорости - по ним Эльбрусы сравнимы и в одной ситуации даже превосходят все остальные процессоры. Там же есть данные по тактам на байт (Эльбрусы уверенно превосходят), что здесь подчёркивается как качество микроархитектуры Эльбрусов.
Большое спасибо за интерес и статью, отличный результат! Вы прямо-таки исполнили моё тайное желание: после появления статьи захотелось посмотреть, как будет выглядеть реализация шифрования на подобном DSP и какой результат получится. И тут Вы - не в бровь, а прямо в глаз!
По поводу скорости: на мой взгляд, 17 тактов на байт при последовательной обработке - замечательный результат. Вообще, меньше 20 уже очень хорошо (современные Intel и AMD тратят около 22 в тех же условиях).
Большая проблема приведённой в статье таблицы — это перечисление характеристик конкретных выпущенных процессоров. Вы берёте конкретные модели и обобщаете их опыт на весь подход. Данные образцы отстают, но является ли это свойством архитектуры на базе VLIW? А как же вопрос затраченных на разработку ресурсов. Неудача гиганта уровня Intel заставляет задуматься, но весьма вероятно, что из-за отсутствия быстрого успеха они потом вкладывали в IA-64 меньше, чем в x86. А исходная неудача IA-64 — это, естественно, сумма факторов, недостатки VLIW в которой сыграли не в первую очередь.
Тем не менее, примеры из реального кода были бы намного более интересны и содержательны (естественно, на горячих циклах). Можно справедливо допустить, что появление других операций приведёт к изменению поведения компилятора и отказу от подстановки функции. Но это приведёт и к увеличению наполненности ШК. Так что возникает вопрос: сохранится ли отставание в более сложном примере? Уверен, оно наоборот сократится.
К тому же, Эльбрус невозможно рассматривать в отрыве от конкретного компилятора. Не скажу, что это хорошо, это создаёт определённые неудобства разработчикам. Тем не менее, есть факт: при использовании различных версий компилятора ощущаются существенные различия. От версии 1.23 до 1.26 наблюдается улучшение производительности, в частности, от подстановок функций, которые раньше не происходили. Насчёт более ранних версий не знаю, не использовал, может быть, там не было видимого роста.
Потом следует отметить, что ваш пример показывает, с какими проблемами можно столкнуться из-за отсутствия предсказателя переходов. Точно так же можно привести альтернативный пример: условный переход в цикле. Традиционно компиляторы под x86-64 генерируют код с переходом. Ручное переписывание с заменой условного исполнения на арифметические операции позволяет добиться кратного ускорения. С другой стороны, из-за предикатного исполнения на Эльбрусе такой проблемы нет. И ни один из этих примеров не показывает явного преимущества одной архитектуры над другой.
Кажется, появление предсказателя переходов решит определённый пласт проблем. Почему его довольно давно обещают, но ещё не сделали — это не выглядит как технический вопрос. Но отсутствие предсказателя — это недостаток строго текущей версии архитектуры, а не идеи в целом. Боюсь, заявлять тупиковость развития на основании этого — слишком громко.
Действительно, не понимаю, как можно сравнивать inlining и VLIW. Подстановка функции - это техника оптимизации, работает под любую архитектуру, в том числе VLIW, в том числе Эльбрус.
И этот вопрос я адресую именно вам, потому что автор верно понял мой первый вопрос и ответил на него, а подмена понятий началась у вас.
Боюсь, вы были невнимательны при чтении статьи. Речь о том, сколько будет выполняться тело цикла, если не удалось подставить функцию (например, она в другом модуле компиляции). Или вы считаете Эльбрус настолько отстающим, что у него одно целочисленное сложение занимает 17 тактов?
Вопрос про цикл с вызовом функции. Вы проверяли, какой получается результат? 17 тактов в случае Эльбруса кажется реалистичным результатом. Но вот один такт на других архитектурах - не верится совсем.
Я понимаю, что вы нацелились на самую широкую аудиторию, но заявляете техническое рассмотрение вопроса, а значит нужно больше деталей. Если это скучные детали, можно скрыть их под спойлер, большинство сможет пропустить.
Всё ещё сильно зависит от режима шифрования. При прикладном примении (ipsec, tls) лучшим вариантом по скорости будет MGM, но тогда надо все значения скорости поделить на 2 (особенность режима). Если брать другие режимы с аутентификацией, то там даже невозможно организовать параллельную обработку блоков, так что скорость упадёт совсем сильно.
С незначительными модификациями реализация переносится на новый актуальный ГОСТ 34.12-2015 - алгоритм Магма.
Было бы интересно подробнее узнать про wave формы, как узнать, где "тормозит конвейер" и прочие детали. Хотя бы пару ссылок.
Листинги ассемблера, наверное, стоит убрать под спойлер, а то занимают основную часть статьи.
Ну и хотелось бы, конечно, больше информации про то, какую реализацию брали и способ замера. Без подготовки читать ассемблер невозможно, а вычленять из него идею — и того хуже. И почему именно разбивка 6+4 на ALU/SIMD? Кажется, что при наличии 32 регистров NEON можно уместить обработку больше, чем 4 блоков, что должно положительно сказаться на скорости. Про замер интересует хотя бы режим шифрования (ECB?), наличие работы с памятью или шифрование на месте в цикле...
В существование чего именно вы не верите? Описание реализаций достаточно подробное, можете самостоятельно повторить результаты и даже, вполне возможно, превзойти их. Стандарты на эти шифры достаточно свежие, идеи, лежащие в основе реализаций, тоже не назовёшь слишком старыми, так что аналогия с абстрактным тестом 2003 года мне не ясна. Если нет уверенности в существовании процессоров, то вынужден огорчить: они существуют и к ним легко можно получить удалённый доступ. Кроме, пожалуй, инженерных образцов последнего поколения, они пока не выставлены в общий доступ.
Что именно вы хотите этим сказать? Если пересчитать данные из статьи, то выходит, что core i7-9700K показывает больше 25 Гбит/с на всех ядрах, а Эльбрус-16С может выдать порядка 56 Гбит/с.
В статье как раз есть ссылка на руководство, в нём уже много информации (это как раз в мае прошлого года случилось). Больше открытой информации пока не было, но и имеющейся достаточно для хорошего старта.
По поводу приобретения лично пока не интересовался, но у физических лиц уже достоверно есть машины в личном пользовании, в чате могут проконсультировать.