информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медГде водятся OGRыSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hardware
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Я немножко не об этом... 30.06.03 13:43  Число просмотров: 1340
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
> Это, когда первые 386 появились. Многие ждали прироста
> производительности в 2 раза. Оказывается нужны приложения,
> адаптированные по 32 разряда и ОС соответствующая. ФоксуПро
> побарабану оказалось. Он все числовые данные в цифровом
> виде хранит и обрабатывает, судя по всему, тоже. Если же
> использовать 16 битные переменные, то ни от 32 разрядов, ни
> от 64 проку не будет. А так, если в программе используются
> 64 битные переменные, то при использовании такого действия,
> как сложения будет использоваться одна инструкция на 64
> разрядах вместо двух, а при умножении и того меньше. Вот и
> выирыш производительности посчитать можно. А лучше
> потестировать. Еще нужно учесть архитектуру (сколько
> инструкций за такт процессор делать может), а то все эти
> ухищрения (переход на 64 бит) не будут иметь смысл. В БД
> для денежных величин 32 разряд мало 4 млрд. рублей для
> крупной организации - не деньги. А вот 64 - выше крыши -
> все деньги на планете в копейках пересчитать можно. И если
> в БД перейти от цифровой формы в 64 битную бинарную -
> прирост производительности будет примерно на порядок. Так,
> что все от реализации зависит.
Subj. Я о том, что NT4 не было в природе 64-битной (имхо). Её тупо портировали из того что было на Alpha. Мы её хотим юзать на Альфе. Ведь широкие целочисленные регистры не только в вычислениях используются, они и память туда-сюда копируют, инициализируют, ищут значения в строках и проч. Вот, даже сандрой тест памяти делаешь на Intel, то видно, что скорость копирования памяти с использованием 8, 16, 32 и FPU регистров линейно возврастает. А это очень большая часть исполняемого кода в программах. Да и тот же SQL-сервак, он вообще «большая и глупая инструкция MOV а-ля Microsoft» ;-))
<hardware> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach