Намного больше чем кажется :)>> Имеется обратный успешный опыт, сравнение ограничу
>> архитектурой x86 Intel/AMD уже оптимизированных
>> оконечных реализаций.
>> ГОСТ 28147-89 простая замена на 10% быстрее на x86-64.
>> ГОСТ 34.310-95 формирование/проверка ЭЦП быстрее в ~3 раза.
>> ДСТУ 4145-2002 формирование/проверка ЭЦП на 50% быстрее.
> А можно узнать, какой процент рабочего времени компьютер
> занимается криптографическими расчётами?
Хотя, незаметно для пользователя, в той или иной мере это используется повсеместно, но это далеко не всё.
Криптография тут - как пример, в общем то, довольно показательный хоть и кажется узким.
На самом деле, разрядность в плане больших чисел - это далеко не только шифрование... :)
И верно подмечено, что требуется часто напильник, либо, для обхода ограничений (ограниченности) компилятора, либо, языковой среды. Но, так же есть и косяк разработчиков конечного софта (хоть системный хоть прикладной), которые просто почему то не пользуются возможностями учитывающими большую разрядность. По разным причинам, подозреваю, в силу банальной привычки.
А вот если учитывается это, то мы заставляем работать железку должным образом а не тупить переливая по пол стакана...
Это касается как правило софта, который явно (и по честному) декларирован для "64".
Кстати, говорить что 32 разрядные приложения "быстрее" в этом случае - это поверхностное суждение, ибо это мнение о приложениях ("64 разрядных") которые так называются но по сути написаны на 32 и часто на 16 разрядном старом коде (библиотеки).
В своё время, адаптируя ГОСТовский алгоритм на паскале, столкнулся с тем, что там нет возможности использовать 64 разрядный блок за один проход, т.к. int64 знаковый... пришлось бить на порции по 16 бит, это оказалось эффективней - но что это? траблы железа, среды, или языка???? Вспомните как выглядит двойное длинное целое в С/С++... так из чего там структура состоит?
Вообще, странно слышать споры о превосходстве той или иной разрядности... что, разговоры о 16 & 32 уже утихли? :)--
С уважением,
Виктор mailto:PyrVic@gmail.com