На нашем сайте проходит массовое обновление тестов, используемых для оценки производительности процессоров и материнских плат. В частности это вызвано тем, что некоторые ранее использованные тесты уже не «справляются» с возросшими скоростными характеристиками современных процессоров, а другие морально устарели.
В этой статье вашему вниманию предлагается изучение еще одной программы, которая может служить одним из тестов для процессоров. А поскольку недавние истории с 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 пакет так же может использоваться для оценки производительности, однако в этом случае тест скорее является синтетическим.
Минус данного теста в том, что он имеет слишком простую зависимость от процессора — линейно по частоте для каждой архитектуры. Так что по настоящему интересные результаты будут получаться только в момент выхода процессоров с действительно новыми ядрами.
