Re: установка Debian
On 2010.05.20 22:23, Victor Wagner wrote:
On 2010.05.20 at 23:32:09 +0600, Виктор wrote:
Не хочется вступать в полемику.. :)
Замечу только:<<длинные>> адреса - да, но и большие числа, есть
подозрение, используется не только в криптографии... Пережиток в
Вот за криптографию я могу сказать точно - от 64-битности одни тормоза.
Причем выигрыша за счет 64-битности не удается добиться не только на
ублюдстве от intel/amd но и на sparc.
Имеется обратный успешный опыт, сравнение ограничу
архитектурой x86 Intel/AMD уже оптимизированных
оконечных реализаций.
ГОСТ 28147-89 простая замена на 10% быстрее на x86-64.
ГОСТ 34.310-95 формирование/проверка ЭЦП быстрее в ~3 раза.
ДСТУ 4145-2002 формирование/проверка ЭЦП на 50% быстрее.
Конфигурация для x86-32 и x86-64 одинакова. Различия в разрядности
ядра ОС.
Шифрование за счет использования меньшего числа операций на базовый
цикл цикл зашифрования (11 инструкций в x86-32 по сравнению с 10 в
x86-64).
ГОСТ 34.310-95 за счет перехода к аппаратному 64-битному умножению
c 128-битным результатом (вроде длится 4 такта).
Это легко реализуемо в GCC из-за поддержки
встроенного 128-битного типа uint128_t.
Intel C compiler, MSVC, Sun Studio compiler, C for AIX,
cc из zOS к сожалению на уровне синтаксиса не поддерживают
встроеный 128-бытный тип. Нужно каверкать исходные тексты на Си
различными ухищрениями, такая красота не получится
prod(uint64_t *a, uint64_t *b, uint64_t *r, int len)
{
...
uint128_t prod =
(uint128_t) a[i] * (uint128_t) b[i] /* это только в GCC */
+ r[i+j] + carry;
r[i+j] = (uint64_t) prod;
carry = (uint64_t) (prod >> 64);
...
}
А собирать нативными компилерами приходится.
cc из zOS бинарно не совместим с GCC на zOS.
Но само больно что mingw64 C compiler не был по крайней мере 1 год
назад бинарно совместим с MSVC x64.
У sparc - нет произведения 64 на 64-бита с 128-битным
результатом одной командой.
Можно вычислить отделно младшую и старшую части.
И вообще корпоративные архитектуры sparc/power/zSearies по сравнению
с x86 на одинаковых частотах выдают производительность
криптографических примитивов в 2-5 раз меньшую.
Не предполагалось видать их использование в качестве числодробилок.
В ДСТУ 4145-2002 переход к 64-битным словам, конечно, не дал прироста
производитльности в разы из-за отсутствия аппаратной операции
произведения полиномов.
Как вывод - математика больших чисел ускоряется значимо при переходе к
64-битам, но требует доработки исходных текстов
(мы ввели типы word_t и dword_t).
Примитивы типа шифрования/хеша от простой перекомпиляции на x64
совсем не на много ускоряются (в основном за счет большего числа
регистров и улучшеного ABI). Можно сказать что требуется ручная
оптимизация с учетом особенностей архитектуры.
Еще замечу что 32-битный Intel C compiler рвет в клочья
GCC, но вот когда регистров куча (в x64) - GCC перестает тупить
(хотя может быть интеловцы забили на 64 битный компилер??)
и результаты получше Intel C.
И Джава лучше себя показывает на x64 (по крайней мере
при выполнении численных алгоритмов).
--
С уважением, Александр Гавенко.
Reply to: