SweetLow
Везде кривость ручек. Если писать все правильно, переполнений не будет. Просто размеры буфера проверять надо.

Добавлено спустя 2 минуты, 3 секунды:
Enot
Это всё зависит не от разрядности, а от правльности реализации алгоритмов запроса и подсистемы памяти. Это уже е проблема процессора

nickyoz
Overflow-эксплойты весьма нетривиальными бывают. Да и со слов Криса Касперски, средний размер переполняемого буфера - 8 байт (!). Я в этом, правда, не уверен, но Крис с данным вопросом по-моему неплохо знаком, так что, скорее всего он прав.
NX есть часть PAE в AMD64, так что 64-битность там, в принципе, не важна (другой вопрос, что PAE само по себе расширяет адресацию памяти выше стандартных 32 бит). Но без PAE NX-а не будет. Защиту от атаки переполнением буфера он обеспечивает очень высокую, хотя и не абсолютную (потенциально можно осуществить весьма изощренную атаку без засылки shell-кода, а просто действуя "руками приложения").

Enot
[q]Скорость будет одинаковой. Процессор читает сразу всю строку кеша, т.е. 64 бита. Что для 32 битов, что для 64 битов - скорость будет одинаковой или почти одинаковой[/q]
Нет, не будет. В загружаемые за такт шины 64 бита можно впихнуть 2 32-разрядных указателя; в кэше можно сохранить вдвое больше данных и так далее по аналогии . Другой вопрос, что в AMD64 сделали такую любопытную вещь: если в обычном 32-битном режиме присвоение младшим разрядам регистров (AX, например) расценивается именно как присвоение младшим 16 разрядам регистра EAX, то в 64-битном режиме присвоение младшим регистрам (EAX, например) автоматически обнуляет старшие разряды (биты 32-63 регистра RAX в данном случае). Так что в 64-битном режиме при выполнении некоторых требований (размещение памяти приложения в нижних 4Гб VRAM - "маленькие программы") можно свободно оперировать с 32-битными указателями, не обращая внимания на то, что они на самом деле 64-разрядные: старшие нули автоматом подставит процессор. Кстати, этот же прием снимает требование 64-разрядности индексов массивов (т.е. даже при полноценной 64-разрядной адресации для не слишком большого массива достаточно иметь один 64-битный указатель, а все индексы оставить 32-битными). То есть даже в 64-разрядном long mode в K8 использование 64-битных чисел никто не навязывает.

nickyoz Это на основании личного опыта заявление, или в стиле "дайте в руки мне баян, я порву его к х"?

Нимб святого не жмет?

Enot То есть ты утверждаешь, что чтение цепочки из 1G указателей на следующую ячейку (без интерливинга) будет одинаково быстрым? Вынужден тебя разочаровать - ровно в 2 раза разница будет. Поскольку ровно в 2 раза больше физически памяти в последовательном режиме придется прочесть.


Это если указатели хорошо перемешаны - т.е. имеем не последовательный, а произвольный доступ. Там вообще скорость не размером определяется(->пропускной способностью), а задержками памяти.

SweetLow Да? А как же Т.к. задержки памяти не зависят от разрядность, то искорость будет одинаковой!?!

Короче, я же писал, что разница будет из-за размера кеша и немного пропускной способности пямяти, но эта разница будет не принципиальной/не большой!

Enot
Короче, я же писал, что разница будет из-за размера кеша и немного пропускной способности пямяти, но эта разница будет не принципиальной/не большой
Кстати, соглашусь с этим утверждением . Не так уж много места в памяти указатели и индексы занимают, + возможность использования стандартных 32-битных указателелей / индексов сохраняется. Но потенциально всё же проигрыш - вплоть до двухкратного, да и процентов 10-20 в скорости если всё делать "в лоб" тоже потерять можно запросто.

Enot
SweetLow указал на вырожденный случай, когда чтение из памяти, фактически, будет последовательным (вследствии структуры данных), но прочитать придется вдвое больше...

Добавлено спустя 8 минут, 11 секунд:
0serg
Выигрыш возможен только от оперирования операндами большей размерности, например деление 64 бита на 64 бита можно делать одной командой, а не несколькими...

STranger_
Выигрыш возможен только от оперирования операндами большей размерности, например деление 64 бита на 64 бита можно делать одной командой, а не несколькими...
Проблема в том, что целочисленные операции большой разрядности сейчас используются крайне редко... Если нужно что-то посчитать, предпочитают использовать арифметику с плавающей точкой, которая от 64-битности ничего не выигрывает (и так 64-битные double сто лет как используются и даже быстрее работают, чем 32-битные float). Впрочем, 64-битный int, в принципе, позволяет организовать полноценную арифметику фиксированной точности на приемлимом диапазоне чисел - хотя перспективы такого решения спорны.
Поэтому в AMD64 и не стали делать ставку на 64-битность: в ней 64 разряда - следствие использование SUMA и серверная ориентированность K8 и, как следствие, необходимость поддержки больших объемов RAM. Для увеличения скорости увеличили вдвое (фактически - даже больше, с учетом служебных функций основных регистров) число GPR и SSE (XMM) - регистров, да кой-чего ненужного, но тормозного повыкидывали.

здесь уже была новость:
на 64битной бете винды с 64битной версией фпс в FarCry подрос на30-40%

0serg Сервер, поддерживающий много SSL соединений одновременно, придерживается прямо противоположного мнения

Собственно разрядность линейного указателя суть разрядность самого процессора. Все остальное (разрядность целочисленной арифметики) плавно вытекает из размера указателя (поскольку над ним тоже надо производить арифметические действия). То есть больше разрядность целочисленных операций может быть (допустим 128 бит - вполне реально), но меньше - нет в принципе (во всяком случае на процессорах с арифметически регистрами, используемыми и как указатели).

Добавлено спустя 4 минуты, 55 секунд:
0serg Да нет, не спорны. Классический финансовый тип данных - 64 битное фиксированной точности с четырьмя десятичными знаками после запятой. Все операции - как с 64 битными целыми с масштабированием.