Производительность 32-разрядных целых чисел в 64-разрядной среде (C++)
От msdn:
порядок возвращенных имен файлов не гарантируется; используйте Вид () метод, если определенный порядок сортировки требуется.
Вид () методом является стандартный Массив. Вид (), который берет в IComparables (среди других перегрузок), поэтому если Вы сортируете по дате создания, она обработает локализацию на основе настроек машины.
6 ответов
Я думаю, у вас есть огромный случай недоразвитой оптимизации, смотрящей вам в глаза. Никогда не вносите подобные микроизменения в свое приложение, пока профилировщик окончательно не скажет вам, что это является источником серьезных проблем с производительностью.
В противном случае вы потратите много времени на исправление неполадок.
Что ж, если 32-битные операции выполняются в 64-битных регистрах, некоторые дополнительные инструкции должны быть выпущены для обработки таких вещей, как установка флагов переноса / переполнения и т. Д., Я бы был удивлен, если вы заметили какое-либо заметное улучшение производительности. Я могу почти гарантировать, что в вашей программе есть гораздо более узкие места.
Не делай этого. Это просто означает, что ЦП не сможет хранить столько данных в кеше, а штраф за переход в основную память намного выше, чем у большинства других вещей.
Идея о том, что использование 64-битного целого числа вместо 32-битного целого числа ускорит процесс, является мифом. Более важным в вашем коде является использование соответствующих типов. Например, при обращении к размеру массива или структуры данных используйте size_t , потому что это то, что должно представлять size_t . Если вы сохраняете какой-то фрагмент данных, используйте int , а не size_t , потому что это int должно описывать.
Дон. Просто не меняйте все на size_t , потому что он «автоматически станет 64-битным», это, вероятно, не приведет ни к каким улучшениям. Это вызовет большие накладные расходы памяти, что, вероятно, приведет к замедлению работы приложения из-за промахов кеша из-за большего объема памяти. Это также вполне может вызвать неожиданные ошибки.
Я предполагаю (и это всего лишь предположение), что вы, скорее всего, не увидите улучшения производительности и может немного снизиться, если увеличение объема памяти приводит к потере локальности ссылок при доступе к памяти и более частому выталкиванию объектов из кеша.
Как ДжаредПар говорит , если нет фактических данных причина для этого или если вам не нужен увеличенный диапазон больших int, это, вероятно, пустая трата времени.
Во-первых, использование 64-битных целых чисел вместо 32-битных целых чисел в 64-битной среде обычно ничего не ускоряет. В зависимости от контекста и возможностей компилятора это может действительно замедлить работу. Обычно вы должны предпочесть использовать типы int / unsigned int для хранения целочисленных значений в вашей программе, переключаясь на другие типы только тогда, когда это действительно необходимо. В конце концов, окончательный ответ на вопрос может быть получен только с помощью реального эксперимента, поскольку он зависит от слишком большого количества переменных.
Во-вторых, любой, кто посоветует использовать для этой цели size_t (в качестве общего беззнаковый тип) следует немедленно отказать в доступе к коду и отправить в некоторые классы C / C ++, прежде чем им снова будет разрешено прикоснуться к коду.