Развенчание мифов об x32 ABI

Все же, а так ли нужны 64-разрядные данные?
Мне всегда казалось, что 64х система — это в первую очередь возможность иметь неограниченное (в ближайшей исторической перспективе) адресное пространство. И лишь значительно потом — целые 64-разрядные числа. Смысла в 64-битной арифметике я лично особого не вижу. Там где действительно нужны такие числа, вполне себе используется float/double.
Платформу же, где реализовали 64-битность, но при этом забыли вставить FPU, найти, наверное, можно, но далеко не на каждой улице.
Я понимаю, что openstreetmap дальше на 32-разрядном инте уже не может, но это далеко не столь частая ситуация…
В общем для меня 64-битность начинается в первую очередь с адресов, а не с данных…

Хочу заметить, что когда мы говорим об «указателях», нужно помнить, что heap поддерживается как раз кучей структур, состоящих из двух или трех указателей, так что если приложение выделяет много небольших объектов (а таких приложений немало), то можно ощутить разницу. Если на рядовом десктопе (где минимум 4gb ram сегодня) эта разница и может показаться незначительной, то на всяких VDS-ках это уже может пригодиться.

Говоря о применении IMUL, автор не прав.
MSVC последний использует imul для доступа к элементу массива по индексу

class Player
{
public:
        char name[437];
} *players;

bool hasName(size_t playerNo)
{
        return players[playerNo].name[0] != '\0';
}

hasName:
mov     rdx, cs:[players]
xor     eax, eax
imul    rcx, 1B5h
cmp     [rcx+rdx], al
setnz   al
retn

Удивительно, что человек такие тексты пишет, и при этом, похоже, совершенно не понимает, как оно работает. Например он удивляется, как много указателей в С-библиотеке. А он задумывался, что в программе вообще-то как раз и используются в основном указатели? Массивы, структуры, объекты, процедуры, методы — указатели. А что, вообще не указатели в современном коде? Переменные? Так, для доступа к ним всё-равно будут сгенерированы указатели. А как иначе процессор «узнает» где они находятся? Даже стек и тот фактически является указателем. И все эти вызовы функций — тоже указатели. И передача параметров через стек — тоже работа с указателями. 99% кода — работа с указателями.
И про то, что не нужно бояться загрязнения стека, нужно просто правильно располагать данные… Во-первых, «правильно» располагать, это вовсе не тривиально. И чем меньше гарнулярность, тем больше будет оптимального кода. Во-вторых, «располагает» не только программист. Передача параметров через стек и локальные переменные тоже требуют выравнивания. И программист на это повлиять фактически не может. А там тот ещё адов ад может твориться. Активная работа с 64-битными указателями ( а как уже говорил выше, это активная работа может возникнуть совершенно на пустом месте — передача несколько объектов в процедуру и работа с ними) может в разы более сильно загрязнить стек. Данных в стеке станет в два раза больше, а ассоциативность кэша процессоров ограничена — будут вытеснены какие-то иные данные по совершенно другим (кратным) адресам. Фактически, переход на 64 бита требует удвоения пропускной способности памяти, размера кэш-памяти и уровня её ассоциативности (а с этим ОЧЕНЬ трудно. Тут просто миллионом транзисторов не отделаешься. Да и при современном развитии многопоточности ассициативность лишней не бывает). И есть мнение, что мы не видим резкого падения при переходе на x64 только по той причине, что там система команд и регистров более сбалансированная (нет бремени совместимости с древним x32/x16 кодом) и за счёт этого узкие месте нивелируются большей степенью оптимальности кода (больше регистров, более универсальная и регулярная система команд). Если совместить более плотную модель памяти (фактически x32 ABI) и новую архитектуру, то на этих узких местах можно получить заметный прирост производительности.
Короче, есть такое мнение, что здравое зерно x32 ABI есть. И не малое. Очень странно, что это не было внедрено сразу (что было бы крайне логично и облегчило бы миграцию x32 на x64). Имеет ли смысл сейчас — уже большой вопрос. Пока индустрия перейдёт, процессоры могут развиться на столько, что эти узкие места станут не актуальны.