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

[nerudo]

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

[datacompboy]

да, нужны. примите как должное.
если ваши задачи не встречают их — то просто поверьте, поймёте потом.

[AterCattus]

Размеры файлов/смещения в файлах тоже в double? Ну будет из-за округления плюс минус один байт, подумаешь. А еще счетчики, временные метки, вычисления с большими промежуточными значениями.

[datacompboy]

а ARM без FP вообще не редкость…

[beeruser]

Казалось бы, причём тут x32. В любом случае ARMv8 без fpu не будет

[FSA]

В OpenStreetMap уже столкнулись с проблемой 32 бит для указателей на объекты. Некоторые скрипты просто стали работать некорректно на 32 битных системах. Собственно, всё теперь нужно адаптировать под больший размер. На 64 битных системах сделать это проще просто потому что они такие.

[gnomeby]

Посмотрите презентацию, там много подробностей. Но если вкратце, то 64-хбитная база хороша следующим:
* в 2 раза больше регистров (что хорошо для мультимедия операций)
* более быстрый FP с помощью SSE
* непосредственно 64-хбитные целые, которые нужны для:
** unixtime
** хранения размера файлов больших, чем 2ГиБ

[Sap_ru]

Дык, 32 ABI этому не мешает. Регистров остаётся столько же. FP и SSE тоже. Никто не запрещает использовать 64-битные целые. Единственное, появляется определённая специфика для работы со структурами данных более 2 Гб.

[gnomeby]

Это понятно. Но мы ведём диалог о том, зачем вообще нужны 64-битные данные.

[fshp]

Не забывайте, что fpu-операции на порядок медленнее целочисленной арифметики.

[qw1]

Это почему?
Набросал тупой тестик на умножение

void main()
{
        double z = 1.1212;
        for (int i = 0; i < 1000000000; i++) {
                if ((i & 15) == 0) z = i;
                else z *= 1.4581;
        }
        printf("%f", z);
}

против

void main()
{
        int z = 17;
        for (int i = 0; i < 1000000000; i++) {
                if ((i & 15) == 0) z = i;
                else z *= 37;
        }
        printf("%d", z);
}

версия с int работает 1.1 секунду, с double — 0.9 секунды.

[gnomeby]

Ну так вы и напишите здесь.

[dimoclus]

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

[qw1]

Говоря о применении 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

[Sap_ru]

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

[Sap_ru]

Вижу, в комментариях многие не видят разницы между архитектурой 64-бита и ABI-бита. Речь идёт не об отказе от 64-битной архитектуре, а о том, чтобы по-умолчанию использовать 32-битные указатели и за счёт этого добиться более эффективного использования памяти. При этом никто не запрещает использовать 64-битные целые и прочие плюшки x64. Только работа со структурами данных более 2 Гб потребует приседаний в виде отдельного диспетчера памяти и специльного типа указателей.

[Sap_ru]

Тьфу, в середине по ошибке в двух местах написал «загрязнение стека» вместо «загрязнения кэша». Там по смысле понятно.