Каковы издержки использования памяти для 64-битного приложения?

Из того, что я нашел до сих пор, ясно, что программы, скомпилированные для 64-битной архитектуры, используют в два раза больше ОЗУ для указателей в качестве их 32-битных альтернатив - https://superuser.com/info/56540/32-bit-vs-64-bit-systems.

Означает ли это, что код, скомпилированный для 64-битного использования, в среднем в два раза больше RAM, чем 32-разрядная версия?

Я как-то сомневаюсь в этом, но мне интересно, что такое настоящие накладные расходы. Я полагаю, что небольшие типы, такие как short, byte и char, имеют одинаковый размер в 64-битной архитектуре? Однако я не уверен в byte. Учитывая, что многие приложения работают с большими строками (например, с веб-браузерами и т.д.), Которые состоят в основном из массивов char в большинстве реализаций, накладные расходы могут быть не такими большими.

Таким образом, даже если числовые типы, такие как int и long, больше на 64 бит, повлияет ли это на использование ОЗУ или нет?

Ответ 1

Это зависит от стиля программирования (и от языка, но вы имеете в виду C).

Если вы много работаете с указателями (или у вас много ссылок на некоторых языках), потребление ОЗУ увеличивается.
Если вы используете множество данных с фиксированным размером, например double или int32_t, потребление ОЗУ не увеличивается.
Для таких типов, как int или long, это зависит от архитектуры; могут существовать различия между Linux и Windows. Здесь вы видите альтернативы, которые у вас есть. Короче говоря, Windows использует LLP64, а это означает, что long long и указатели имеют 64 бит, тогда как Linux использует LP64, где long тоже 64 бит. Другие архитектуры могут сделать int или даже short 64 бит, но это довольно необычно.
float и double должны оставаться неизменными по размеру во всех случаях.

Итак, вы видите, что это сильно зависит от использования типов данных.

Ответ 2

Есть несколько причин, по которым потребление памяти увеличивается. Однако накладные расходы 64b против 32b зависят от приложения к другому.

Основная причина - использование большого количества указателей в коде. Однако массив, распределенный динамически в коде, скомпилированном для 64-битного и запущенного на 64-битной ОС будет такого же размера, как массив, выделенный на 32 разрядной системы. Только адрес массива будет больше, контент размер будет таким же (кроме случаев, когда размер шрифта изменился - однако это не должно происходить и должно быть хорошо документировано).
Еще одно увеличение размера будет связано с выравниванием памяти. В 64-битного режима, для выравнивания необходимо учитывать 64-битный адрес, чтобы должен добавить небольшие накладные расходы.
Вероятно, размер кода увеличится. На некоторых архитектуры 64-битной ISA могут быть немного больше. Кроме того, вы бы теперь нужно совершать вызовы на 64-битные адреса.
При запуске в 64-битных регистрах больше (64 бит), поэтому, если вы используете многие числовые типы компилятора могли бы также помещать их в регистры, поэтому это не обязательно означает, что ваш объем оперативной памяти будет расти. Использование двойных переменных, скорее всего, приведет к созданию памяти увеличение размера, если они не сохраняются в регистры 64b.
При использовании JIT-компилированных языков, таких как Java,.NET, вероятно, увеличение размера кода 64b будет больше, поскольку среда выполнения будет генерировать дополнительные служебные данные через использование указателя, скрытый контроль структуры и т.д.

Однако нет волшебного номера, описывающего служебные расходы на 64-битную память. Это необходимо измерить из приложения в другое. Из того, что я видел, , я никогда не получал более 20% увеличения footprint для приложения, работающего на 64-битной, по сравнению с 32-битной. Однако это чисто основано на приложениях, с которыми я столкнулся, и я использую в основном C и С++.

Ответ 3

Я думаю, что может возникнуть еще одна причина, которая вернется к тому, что переменные должны храниться в памяти на 64-битной границе по адресу, который... xxxxx000 должен быть прочитан одним прикусом, если ему не нужно его читать в байте за раз.