Производительность 32-разрядных целых чисел в 64-разрядной среде (C ++) - PullRequest
12 голосов
/ 17 ноября 2009

Мы начали компилировать 32- и 64-битные версии некоторых наших приложений. Один из ребят из моего проекта призывает нас переключить все наши 32-разрядные целые числа на их 64-разрядные эквиваленты, даже если значения гарантированно поместятся в 32-разрядном пространстве. Например, у меня есть значение, которое гарантированно никогда не превысит 10000, которое я храню в неподписанном int. Он рекомендует переключить его на size_t, чтобы он расширялся до 64 бит в 64-битной среде, даже если нам никогда не понадобится дополнительное место. Он говорит, что использование 64-битных переменных ускорит работу приложения независимо от значений, хранящихся в каждой переменной. Он прав? Оказывается, это большая работа, и мне не терпится приложить усилия, если это на самом деле ничего не изменит.

Мы используем Microsoft Visual C ++ 2008. Хотя я надеюсь на более общий, независимый от платформы ответ.

Так что ты думаешь? Правильно ли мы тратим время на изменение типов данных в целях повышения производительности, а не диапазона?

Ответы [ 6 ]

17 голосов
/ 17 ноября 2009

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

В противном случае вы потратите много времени на исправление проблем.

9 голосов
/ 17 ноября 2009

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

7 голосов
/ 17 ноября 2009

Во-первых, использование 64-битных целых вместо 32-битных в 64-битной среде обычно ничего не ускоряет. В зависимости от контекста и возможностей компилятора, это может замедлить работу. Обычно вы предпочитаете использовать типы int / unsigned int для хранения интегральных значений в вашей программе, переключаясь на другие типы только тогда, когда это действительно необходимо. В конце концов, окончательный ответ на вопрос может быть получен только в результате реального эксперимента, поскольку он зависит от слишком большого количества переменных.

Во-вторых, любому, кто посоветует использовать size_t для этой цели (как универсальный тип без знака), следует немедленно запретить доступ к коду и отправить его для прохождения некоторых классов C / C ++, прежде чем ему снова разрешат прикоснуться к коду.

4 голосов
/ 17 ноября 2009

Не делай этого. Это просто означает, что процессор не сможет хранить столько данных в кеше, а штраф за переход в основную память намного выше, чем у большинства других вещей.

2 голосов
/ 17 ноября 2009

Идея о том, что использование 64-битного целого и 32-битного целого ускорит процесс, является мифом. Более важной вещью в вашем коде является использование соответствующих типов. Например, при обращении к размеру массива или структуры данных, используйте size_t, потому что это то, что должен представлять size_t. Если вы храните какой-то фрагмент данных, используйте int, а не size_t, потому что именно это и должно описывать int.

Не просто поменяйте все на size_t, потому что оно "автоматически станет 64-битным", что, вероятно, не приведет к улучшению вообще. Это приведет к увеличению объема используемой памяти, что, вероятно, приведет к замедлению работы приложения из-за пропадания кэша из-за увеличения объема памяти. Это также может привести к неожиданным ошибкам.

1 голос
/ 17 ноября 2009

Я бы предположил (и это всего лишь предположение), что вы, скорее всего, не увидите улучшения в производительности и можете увидеть небольшое снижение, если увеличение объема памяти приведет к тому, что некоторый доступ к памяти потеряет локальность ссылок и вытолкнет вещи из кеш чаще, чем раньше.

Как сказал JaredPar , если нет фактической причины сделать это или если вам не нужен увеличенный диапазон больших целых, это, вероятно, пустая трата времени.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...