Использование пакета криптографии OpenSSL для тестирования процессоров


На нашем сайте проходит массовое обновление тестов, используемых для оценки производительности процессоров и материнских плат. В частности это вызвано тем, что некоторые ранее использованные тесты уже не «справляются» с возросшими скоростными характеристиками современных процессоров, а другие морально устарели.

В этой статье вашему вниманию предлагается изучение еще одной программы, которая может служить одним из тестов для процессоров. А поскольку недавние истории с Lame и Xvid показали, что «не все тесты одинаково полезны», мы попробуем в деталях изучить работу нового кандидата.

Речь пойдет о пакете OpenSSL. В этой работе участвовала версия OpenSSL 0.9.7c от 30 сентября 2003 года. Он представляет собой набор программ и библиотек для реализации протоколов SSL и TSA. Кроме того, с его помощью можно выполнять шифрование отдельных файлов, вычислять контрольные суммы и устанавливать/проверять цифровые подписи. Пакет реализует популярные алгоритмы DES/3DES, RC4, Blowfish, IDEA, AES, MD5, SHA/SHA-1, RSA, DSA и другие. Отметим, что OpenSSL часто используется в различных дистрибутивах Linux для организации указанных функций.

Поскольку программа поставляется в исходных кодах, то ее можно использовать в большом количестве различных архитектур. Однако обратной стороной этого положительного момента является необходимость выбора компилятора и его опций (также есть и опции самого пакета).

Кроме исходных текстов на языке C пакет использует и ассемблерную реализацию некоторых процедур. В частности, оптимизацию имеют Blowfish, DES, MD5, RC5, SHA и другие. Допускается использование кроссплатформенного продукта nasm, стандартного ассемблера под win32 от Microsoft (masm) и других. При этом оптимизаций под наборы SIMD инструкций в ассемблерном коде нет.

Безусловно, использование OpenSSL на платформе win32 несёт налет «синтетики», поскольку в основном этот пакет популярен в среде Linux. Однако как один из тестов на скорость процессоров он вполне подходит и с этой точки зрения ничуть не хуже других программ. А наличие исходных текстов может помочь в понимании того, что происходит внутри :). Кроме того, мы проведем тесты и в ОС Linux.

Измерение скорости

Для оценки производительности OpenSSL можно использовать два способа. Первый – это измерение времени реального шифрования файлов командами типа «openssl enc -des -in file_in -out file_out -pass pass:password». Второй способ предусмотрен разработчиками и состоит в запуске openssl с командой «speed» (возможно также указание используемых алгоритмов). При этом все действия выполняются в памяти ПК и влияние жесткого диска исключено. Сравнение этих способов показало, что результаты для скорости шифрования получаются практически одинаковые, и поэтому в дальнейшем использовался второй вариант как более удобный и универсальный (пользователь любой системы с установленным OpenSSL может его использовать).

Результаты выдаются в единицах «тысячи байт в секунду», что удобно – используется принцип «больше, значит лучше» и можно легко сравнить эти данные со скоростью работы сети или жесткого диска. В качестве примера приведу один полный отчет оригинальной версии.


OpenSSL 0.9.7c 30 Sep 2003 
built on: Mon Dec  1 15:44:41 2003 
options:bn(64,32) md2(int) rc4(idx,int) des(idx,cisc,4,long) aes(partial) idea(int)
blowfish(idx) 
compiler: cl  /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo
-DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DBN_ASM
-DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_KRB5 
available timing options: TIMEB HZ=1000 
timing function used: ftime 
The 'numbers' are in 1000s of bytes per second processed. 
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 
md2               1754.48k     3862.38k     5517.01k     6175.47k     6386.45k 
mdc2              6507.84k     8454.66k     9041.88k     9167.25k     9388.48k 
md4              11086.51k    39547.92k   118159.81k   226069.95k   304555.77k 
md5              11132.86k    40289.90k   123248.60k   251862.88k   360994.43k 
hmac(md5)         5973.52k    22492.58k    76082.83k   191329.62k   340827.14k 
sha1              9774.65k    31134.50k    78877.37k   127076.05k   154771.37k 
rmd160            8895.90k    27166.28k    63253.56k    94813.31k   110549.15k 
rc4             100727.76k   112901.86k   116081.20k   116971.46k   117085.74k 
des cbc          51749.59k    52127.44k    51369.31k    39258.72k    46995.00k 
des ede3         20277.03k    20336.01k    20335.99k    18738.05k    19830.74k 
idea cbc         22393.51k    23090.03k    23342.21k    23444.96k    23443.33k 
rc2 cbc          29061.52k    30161.29k    30590.24k    30676.94k    30679.74k 
rc5-32/12 cbc   104759.39k   107892.06k   107374.18k   107374.18k   107926.77k 
blowfish cbc     90614.18k    92157.19k    92974.32k    93362.36k    91779.08k 
cast cbc         70403.76k    75624.14k    76959.71k    77528.72k    72067.08k 
aes-128 cbc      40746.12k    36836.57k    37411.56k    38212.54k    38692.84k 
aes-192 cbc      37807.81k    37282.70k    37411.56k    36033.54k    37023.54k 
aes-256 cbc      32787.21k    32787.21k    32835.34k    32787.21k    32536.05k 
                  sign    verify    sign/s verify/s 
rsa  512 bits   0.0007s   0.0001s   1350.1  13695.9 
rsa 1024 bits   0.0037s   0.0002s    271.3   4794.1 
rsa 2048 bits   0.0227s   0.0007s     44.0   1436.2 
rsa 4096 bits   0.1539s   0.0024s      6.5    412.6 
                  sign    verify    sign/s verify/s 
dsa  512 bits   0.0006s   0.0007s   1646.9   1334.1 
dsa 1024 bits   0.0019s   0.0023s    528.3    432.3 
dsa 2048 bits   0.0064s   0.0079s    155.8    126.6

Как вы видите, результаты собраны в таблицу, где по вертикали идут названия алгоритмов, а по горизонтали (в первой части) – размер блока данных для шифрования/подсчета контрольной суммы. На пересечении стоит цифра скорости обработки данных в «тысячи байт в секунду». Во второй части (тест алгоритмов RSA/DSA) результаты выдаются в единицах «подписей в секунду» (при работе с подписями используется уже готовый дайджест сообщения).

Мы видим, что тесты шифрования показывают примерно равную скорость независимо от размера блока. Хотя иногда наблюдаются и некоторые флуктуации, например у des cbc/des ede3. Дальнейшие тесты показали, что они характерны только для некоторых сочетаний компилятор/опции/процессор и при небольших (до 32 КБ) блоков данных.

Поскольку есть доступ к исходным текстам, то мы провели также тестирование с большими размерами блока — до 16 МБ. Отметим, что скорость алгоритмов шифрования так и осталась на уровне маленьких блоков, а все варианты подсчета контрольных сумм также вышли на стабильный уровень примерно с 1 МБ. Возможно, что для подсчета контрольных сумм маленьких блоков слишком велики накладные расходы и это замедляет работу. Формально можно считать, что программа в случае больших блоков работает с потоками данных и ее производительность может быть измерена как «количество байт, обработанных за единицу времени». Хотя скорость шифрования небольших блоков информации может быть интересна в некоторых приложениях.

Общее время выполнения теста составляет около 20 минут на топовых процессорах для платформы win32. В ОС Linux используются таймеры, и поэтому время работы не зависит от выбора процессора и составляет (в стандартной поставке) около 7 минут.

Обратите внимание на то, что в отчете содержатся и основные параметры, использованные при компиляции теста: имя компилятора, ключи оптимизации, опции настройки отдельных алгоритмов. К сожалению, информация о ключах не является полностью корректной. В указанном выше примере использовался и ассемблерный код для DES, однако это нигде не указано. Также отметим, что в пакете часто встречаются ошибки в описании опций сборки, что заметно затрудняет исследования :(.

Теперь попробуем понять, от каких параметров системы зависят показания теста. Для этого мы провели измерения на широкой линейке процессоров Pentium 4, включая варианты на шинах 400, 533 и 800 МГц, версии с L2 кэшем в 512, 256 и 128 КБ и на разных чипсетах.

Начнем, пожалуй, с частоты. Сравнив результаты тестирования процессоров Pentium 4 с различными частотами, мы увидели, что они хорошо укладываются на прямую линию. Например, разница в скорости между процессором с частотой 3,0 ГГц и 2,4 ГГц составляла по всей таблице алгоритмов и размеров блоков 24,6.. 26,1%, что очень близко к разнице в частоте в 25%. Другие пары показали аналогичные результаты. Этого можно было ожидать, поскольку по данным, приведенным выше, можно оценить скорости потоковой обработки информации — она составляет (Pentium 4 3,06) до 360 МБ/сек для подсчета контрольных сумм и до 110 МБ/сек при шифровании. Эти цифры показывают, что узким местом является скорее процессор и его АЛУ, чем подсистема памяти.

Дальнейшие тесты только подтвердили это предположение. В частности скорость работы теста на системах с одно- и двухканальной DDR памятью (было проверено три чипсета — i875, i848, SiS655) и одинаковым процессором не отличалась.

Проверка влияния частоты FSB на паре Pentium 4 3,06/i875/dual DDR333 и Pentium 4 3,0/i875/dual DDR400 показала независимость и от этого параметра (по всем тестам выигрывал процессор с большей частотой и меньшей скоростью FSB на ожидаемые 2%)

Влияние объема L2 кэша изучалось на примере двух пар: Celeron 1,7 против Pentium 4 1,7 и Celeron 2,4 против Pentium 4 2,4. Кроме случая маленьких блоков самого медленного алгоритма (md2) разницы не было.

На платформах AMD (Athlon XP, Athlon 64/64FX/Opteron) были проведены тесты, которые подтвердили полученные выводы — независимость скорости от объема L2 кэша, скорости памяти и прямая пропорциональность частоте. Таким образом, мы получили, что скорость каждого теста может быть легко получена по формуле скорость = коэффициент * частота процессора. При этом коэффициент определяется исключительно архитектурой процессора. То есть он одинаков для всех Pentium 4 (включая Celeron), всех Athlon (включая XP и Barton), всех моделей архитектуры AMD64.

К сожалению, низкая точность вывода результатов для работы с RSA/DSA ключами и обусловленная малым временем исполнения теста и не очень хорошая повторяемость не позволяют полноценно использовать исходный вариант пакета для точной оценки скорости процессоров. Так что для повышения удобства использования теста программу можно исправить. В частности увеличить интервалы времени, увеличить размеры блоков, изменить шаблоны вывода результатов.

Оптимизация

Поскольку вопрос об оптимизации очень популярен в последнее время, то мы не можем обойти его стороной. Однако сначала хотелось бы прояснить свою позицию по этому поводу.

Начнем с того, что диапазон возможных оптимизаций одного отдельно взятого приложения чрезвычайно широк – от простого указания программе о выборе того или иного алгоритма работы выбором опций командной строки или ключами реестра, до переписывания полностью кода всего приложения на ассемблере с максимальным учетом возможностей используемого процессора. Естественно, если первый вариант не требует особых познаний в железе и ПО (порой достаточно просто прочитать описание программы или рекомендации в форуме), то последний может быть реализован очень малым количеством пользователей. Есть и промежуточные варианты, которые с одной стороны не требуют особых познаний, а с другой могут не дать максимального эффекта. Что выбирать — каждый решает для себя. Кто-то ограничивается установкой оптимизированных под процессор библиотек, а кто-то может и попробовать перекомпилировать приложение (при наличии такой возможности) альтернативным компилятором.

Для тестеров такой большой выбор – головная боль. Легко придумываются несколько вариантов, каждый со своими доводами за и против. В любом случае найдется мнение, что «нужно было попробовать еще вариант две тысячи триста сорок первый» :). Опыт показывает, что истина рождается в споре, и мы надеемся, что наши читатели помогут нам с решением этого вопроса.

Что касается героя этой статьи, то для увеличения скорости счета пакета есть несколько возможностей (не считая конечно экстремального варианта переписывания кода из серии «сделай сам»). Все они реализуются исключительно путем специальной сборки программы. Во-первых, можно использовать ассемблерные вставки. При этом ассемблерный код генерируется специальными скриптами на перле (предоставленными авторами) под разные архитектуры. Во-вторых, можно попробовать различные варианты реализации кода отдельных процедур (также предусмотренные авторами). Ну и, наконец, можно просто выбрать другой компилятор и/или установить другие опции компиляции.

Отметим, что пакет имеет возможность верификации работы всех функций, так что при необходимости можно проверять правильность оптимизаций.

Первый способ приносит заметные дивиденды — если не использовать ассемблер, то код замедляется для разных алгоритмов на 20-70%. Правда ассемблерные вставки существуют «неравномерно» по алгоритмам и архитектурам. В частности для AES есть только код на C, для Blowfish дополнительно есть вариант ассемблера для x86, для MD5 — код на C и ассемблер для x86 и Sparc. Так что в вопросе об использовании ассемблера вопросов не возникает: если есть такая возможность — используем ее. Проблема может быть в том случае, если мы захотим сравнить две различные архитектуры, и для одной из них не будет возможности использования ассемблера, тогда она попадет в заведомо невыгодное положение. В этом случае можно попробовать выключить ассемблер у всех, но это переводит тест из реальности в синтетику.

Второй способ мы попробовали на примере алгоритма DES. Для этого было создано 12 вариантов кода (по всем возможным комбинациям ключей, указанных в файле Configure). Результаты показали, что реальная зависимость от настроек проявляется только при не использовании ассемблера, при этом ассемблерный вариант быстрее всех двенадцати. Самый быстрый вариант на чистом C отстает от ассемблера менее чем на один процент и выигрывает у предлагаемого по умолчанию (без ассемблера) порядка 6%. А вот замедлить алгоритм выбором не оптимальных параметров можно уже на 20%. Правда, все это справедливо для случая компилятора Microsoft. Формально можно ожидать, что хороший компилятор, использующий особенности современных процессоров, может «выжать» большую скорость, чем написанный пару лет назад ассемблер. Так что двенадцать вариантов были собраны и с использованием компилятора Intel с оптимизацией под Pentium 4. В целом результаты аналогичны случаю с MSVC, однако максимум достигается при другом выборе параметров кода DES. Сочетание «компилятор Intel + ассемблерный код» повело себя аналогичным образом: «MSVC + ассемблер» (то есть от опций DES и с этим компилятором практически ничего не зависит).

Третий способ, который мы использовали, – замена компилятора на Intel C/C++ Compiler и выбор опций оптимизации для процессора Pentium 4. Это помогло улучшить показатели большинства тестов. Причем, если у алгоритма (например, DES) был ассемблерный вариант, то новый компилятор не сильно помог. Только с шифрованием IDEA случился конфуз – Intel проигрывает здесь 30%. Информация по отдельным тестам приведена в таблице.

Intel Compiler vs MSVC, %
алгоритм с ассемблером без ассемблера
md2 39 44
mdc2 -7 -1
md4 33 33
md5 -2 12
hmac(md5) 0 11
sha1 0 57
rmd160 0 -7
rc4 0 0
des cbc 0 4
des ede3 -1 10
idea cbc -30 -30
rc2 cbc 14 14
rc5-32/12 cbc -1 35
blowfish cbc 0 264
cast cbc 0 160
aes-128 cbc 115 120
aes-192 cbc 116 122
aes-256 cbc 113 111
rsa 512 bits sign 2 52
rsa 1024 bits sign 3 64
rsa 2048 bits sign 0 70
rsa 4096 bits sign 1 75
dsa 512 bits sign 1 58
dsa 1024 bits sign 5 65
dsa 2048 bits sign 1 73
rsa 512 bits verify 10 65
rsa 1024 bits verify 5 74
rsa 2048 bits verify 3 75
rsa 4096 bits verify 2 77
dsa 512 bits verify 0 52
dsa 1024 bits verify 3 56
dsa 2048 bits verify 1 62

На этом можно закончить оптимизацию теста. А тем, у кого много времени можно предложить переписать make-файл для использования различных компиляторов и ключей оптимизации для каждого из более чем пятисот исходных файлов :).

Резюмируем этот параграф:

  • Использование оригинальных ассемблерных процедур очень помогает. Но их использование ограничивается в основном архитектурой x86.
  • Если нет возможности использовать ассемблер, то можно попробовать выбрать ключи настройки алгоритмов в C коде. Оптимальный выбор может добавить еще несколько процентов скорости. Однако ассемблер обычно быстрее.
  • Использование альтернативного компилятора может помочь использовать все возможности процессора и улучшить скоростные показатели для тестов, написанных на языке C.

Результаты

Как вы видели выше, скорость работы OpenSSL зависит от многих факторов. Используя это приложение, можно провести большое количество различных тестирований. Например, сравнить производительность процессоров, качество оптимизаций компиляторов, скорость работы пакета под разными ОС и так далее. При этом параметров, влияющих на результат очень много (хорошо хоть от железа получилась достаточно простая зависимость), и для подобных сравнений приходится фиксировать какие-то из них.

Для начала мы выбрали сравнение процессоров под ОС Windows XP на коде «по умолчанию»: компилятор от Microsoft плюс ассемблерные вставки. На графиках приводятся данные некоторых алгоритмов для разных архитектур по скорости на 8 КБ блоках (полученные на оригинальной версии OpenSSL).














Мы не будем специально обсуждать результаты «Intel vs AMD», поскольку решение о выборе платформы, компилятора и опций еще не принято. Приведенные цифры можно рассматривать как синтетику. Нужно разобраться и в том, какие конкретно алгоритмы стоит учитывать, так как популярность у них разная.

Теперь попробуем использовать тест под Linux. Благо OpenSource разработкам в ней должно быть привычнее :).

Отметим, что пакеты, которые входят в поставку ОС могут отличаться в зависимости от результата, полученного при выполнения ./config & make. Например, вариант OpenSSL из Mandrake 9.2 использует ключи -march=i586 -mcpu=pentiumpro, а собранный из последних исходников только -mcpu=pentium (остальные ключи оптимизации равны). Ничего плохого в этом нет, однако это затрудняет прямое сравнение. Так, что, вспоминая отсутствие полной информации об используемых ключах в готовом продукте, находим еще одно «преимущество» от общения с опенсурсом (да… да… можно скачать src.rpm и попытаться обнаружить там необходимые данные, но…. :) ).

Учитывая то, что обычно используются готовые пакеты, и мало кто пытается раскопать make-файлы и что-то там исправить, подход к сравнению простой: можно либо использовать версию из дистрибутива системы (надеясь на мастерство поставщика), либо скачать последнюю версию тарбалла и собирать ее, не сильно вдаваясь в подробности компиляции. Но, безусловно, и в Linux можно попробовать увеличить скорость работы OpenSSL настройкой пакета и заменой компилятора.

Для тестирования систем под Linux использовался Live CD с SuSE 9 Pro i386. Благодаря этому тестирование удалось провести быстро и на большом количестве систем. Правда использовался входящий в поставку OpenSSL 0.9.7b с максимальным размером блока 8 КБ, однако для оценки тенденций и этот вариант подходит. Отметим, что на десяти системах (использовались ПК сотрудников, от Athlon 800 через десктопы и ноутбук на Pentium 4 до систем на Athlon 64 и Athlon 64 FX) дистрибутив заработал «легко и непринужденно» :). Только неправильно определяемое разрешение монитора в XFree86 несколько раз не позволило сразу работать в графическом режиме.














Эти диаграммы можно считать измерением скорости реального приложения. Хотя, конечно, чаще используется собственноручно собранная последняя версия пакета. Отметим, что не наблюдается разницы в скорости с win32 вариантами на большинстве диаграмм. Из заметных отличий отметим падение AMD в DES3 и рост у Pentium 4 в AES.

Теперь попробуем поискать счастье от 64 бит на AMD64 под 64-х битным Linux. Благо именно OpenSource проекты для этой цели очень хорошо подходят. Конечно ручная оптимизация кода на ассемблере более эффективна, однако оценку «а что я с этих 64-х бит получу?» найти можно.

Посмотрим на скорость пакетов OpenSSL 0.9.7b, предустановленных в системе SuSE 9 Pro для архитектур i386 и AMD64. В таблице представлено сравнение на блоках по 8 КБ для старой версии и 16 МБ для версии новой. Отметим, что поддержка idea и rc5-32/12 не входит в поставляемый с дистрибутивами пакет OpenSSL.

AMD64 vs i386, %
алгоритм OpenSSL 0.9.7b
из поставки
собранный
OpenSSL 0.9.7c
собранный OpenSSL 0.9.7c без ассемблера
md2 -6 -7 -8
mdc2 39 -2 4
md4 -24 -4 -3
md5 -52 -29 -5
hmac(md5) -51 -29 -5
sha1 -33 -23 41
rmd160 -44 -14 15
rc4 -25 -35 -28
des cbc -26 -28 2
des ede3 -17 -23 1
idea cbc   -6 -6
rc2 cbc 11 2 2
rc5-32/12 cbc   -24 90
blowfish cbc -17 -15 -7
cast cbc 35 -33 -20
aes-128 cbc 57 44 46
aes-192 cbc 60 46 47
aes-256 cbc 64 47 48
rsa 512 bits sign 83 91 184
rsa 1024 bits sign 122 181 283
rsa 2048 bits sign 112 208 345
rsa 4096 bits sign 110 225 391
dsa 512 bits sign 114 153 256
dsa 1024 bits sign 109 191 328
dsa 2048 bits sign 109 213 379
rsa 512 bits verify 93 104 220
rsa 1024 bits verify 96 145 310
rsa 2048 bits verify 101 189 375
rsa 4096 bits verify 108 212 422
dsa 512 bits verify 113 165 252
dsa 1024 bits verify 108 189 312
dsa 2048 bits verify 112 211 388

И вот она «радость» в виде падения скорости в большинстве тестов подсчета контрольных сумм и шифрования. Но, увы, чуда не произошло.

Не стоит долго разбираться в таком поведении теста. Дело в том, что в варианте AMD64 (кстати, присутствующем в конфигурационных файлах OpenSSL) не используются ассемблерные процедуры. Точнее есть только один файл для реализации работы с «большими числами», причем в версии от декабря 2002 года и, скорее всего, автор не имел доступа к системе на AMD64 во время его создания. Не использование ассемблера косвенно подтверждается ростом показателей AES/RSA/DSA, для которых его не предусмотрено. Кстати отметим, что этот рост очень даже значительный – двукратный в тестах RSA/DSA и в 1,6 раза в AES (на оригинальной версии).

Новая сборка OpenSSL версии 0.9.7c с настройками на linux-ppro (максимальный x86 вариант из поставки) еще больше усилила неравенство: CAST перешел в лагерь отстающих (за счет сильно возросшей скорости 32-х битного кода), преимущество AMD64 в AES уменьшилось, однако на RSA/DSA 64-х битный код отыгрался.

Если отключить использование ассемблера, то можно попробовать оценить качество компилятора под AMD64 и его способности по использованию всех возможностей архитектуры. Как видно по таблице, он достаточно хорош. Хотя многое зависит и от исходного алгоритма. Например, на RC4 и CAST он показал результат хуже, чем на i386, а RSA/DSA ему понравились. При этой оценке не нужно сбрасывать со счетов и адаптацию исходных файлов под 64-бит архитектуру. Так увеличение скорости в некоторых тестах в 5 (!) раз заслуга не только компилятора.

Заключение

Исследование OpenSource пакета криптографии OpenSSL показало, что его можно использовать в качестве теста для процессоров и компиляторов. Тем более что задачи и алгоритмы криптографии сегодня актуальны, а эта реализация является абсолютно реальным продуктом. Интерес к задаче обусловлен существованием четкой зависимости скорости работы от производительности процессора :).

Положительным моментом использования пакета в тестах является его большая популярность в среде Linux для выполнения процедур, связанных с криптографией. На платформе win32 пакет так же может использоваться для оценки производительности, однако в этом случае тест скорее является синтетическим.

Минус данного теста в том, что он имеет слишком простую зависимость от процессора — линейно по частоте для каждой архитектуры. Так что по настоящему интересные результаты будут получаться только в момент выхода процессоров с действительно новыми ядрами.



Благодарим компанию VDEL, официального дистрибутора SuSe Linux AG в России, за помощь при проведении тестирования



Дополнительно

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.