Опять таки вопрос вам: много-ли *пользовательских* приложений используют все
возможности 64-разрядности? Прошу привести конкретные приложения со
статистикой потребляемой памяти и быстродействием выполнения операций так
же, как вы приводили примеры выполнения *вами* *написаного* кода. Тут я
говорю о браузерах, офисных пакетах, IM и пр.
25 мая 2010 г. 21:45 пользователь Виктор <pyr...@gmail.com> написал:
> *>> Имеется обратный успешный опыт, сравнение ограничу
> >> архитектурой 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:pyr...@gmail.com<pyr...@gmail.com>
> *
>
