При чтении учебного комплекта 70-536 в нем говорится:
Среда выполнения оптимизирует производительность 32-разрядных целочисленных типов (Int32), поэтому используйте эти типы для счетчиков и других часто используемых интегральных переменных.
Это применимо только в 32-битной среде? Int64 берет верх в 64-битной среде, или Int32 по-прежнему является лучшим выбором?
Это забавный способ выразить это. Время выполнения не имеет к этому никакого отношения. ЦП предназначен для обработки 32-битных целых чисел, поэтому они наиболее эффективны в использовании.
В 64-битной среде это опять же зависит от процессора. Однако, по крайней мере, на процессорах x86 (которые, насколько мне известно, являются единственным местом, где работает .NET), 32-битные целые числа по-прежнему используются по умолчанию. Регистры просто были расширены, чтобы они могли вместить 64-битное значение. Но 32 по-прежнему по умолчанию.
Поэтому предпочитайте 32-битные целые числа даже в 64-битном режиме.
Изменить: слово «по умолчанию», вероятно, не подходит. ЦП просто поддерживает ряд инструкций, которые определяют, какие типы данных он может обрабатывать, а какие нет. Там нет "по умолчанию". Однако, как правило, существует размер данных, для эффективной обработки которого ЦП предназначен. А на x86, в 32 и 64-битном режиме, то есть 32-битные целые числа. 64-битные значения, как правило, не дороже, но они требуют более длинных инструкций. Я также считаю, что, по крайней мере, Pentium 4 с 64-разрядной поддержкой были значительно медленнее при 64-разрядных операциях, хотя на последних процессорах эта часть не должна быть проблемой. (Но размер инструкции может быть еще)
Меньшие, чем 32-битные значения несколько более удивительны. Да, данных для передачи меньше, и это хорошо, но ЦП по-прежнему захватывает 32 байта за раз. Это означает, что он должен маскировать часть значения, поэтому они становятся еще медленнее.
Сегодня Скотт Хансельман опубликовал в своем блоге статью, посвященную различиям между 32- и 64-битным управляемым кодом. Подводя итог, в основном только указатели меняют размер, целые числа по-прежнему 32 бита.
Сообщение можно найти здесь.
Если вы не планируете, чтобы значение превышало 2 миллиарда, используйте целочисленное значение. Нет причин использовать дополнительное пространство для повышения производительности.
И вопреки тому, что могут сказать другие люди в этой ветке, пока вы не измерите пользу от такой мелочи, как эта, она будет заключаться только в ощутимой пользе.
http://en.wikipedia.org/wiki/64-bit предлагает (вы может найти более авторитетный источник, это первый, который я нашел), что «64-битные» предложения Microsoft используют 64-битные указатели с 32-битными целыми числами.
http://www.anandtech.com/guides/viewfaq.aspx?i=112 (и я не знаю, насколько это достоверно) говорит:
Чтобы свести к минимуму раздувание кода, AMD фактически устанавливает размер операнда данных по умолчанию равным 32 битам в 64-битном режиме адресации. Причина в том, что 64-битные операнды данных вряд ли потребуются и могут снизить производительность; в тех ситуациях, когда желательны 64-битные операнды данных, их можно активировать с помощью нового префикса REX (у-у-у, еще один префикс инструкции x86 :)).
32-битный процессор быстрее обрабатывает 32-битные целые числа. 64-битный быстрее обрабатывает 64-битные целые числа; просто подумайте об этом - вам либо нужно все время сдвигать биты на 32 бита, либо тратить 32 бита на каждые 32 бита, что по сути то же самое, что использовать 64-битную переменную без преимуществ 64-битной переменной. Другим вариантом было бы встроить в ЦП дополнительную схему, чтобы не было необходимости в переключении, но, очевидно, это увеличило бы производственные затраты. Это то же самое для 32-битных процессоров, обрабатывающих 16-битные или 8-битные переменные.
Я не уверен, но я не удивлюсь, если 64-битный вариант .NET Framework будет немного более оптимизирован для использования длинных чисел, но это всего лишь предположение с моей стороны.
