.NET Optimized Int32

Question

При чтении учебного комплекта 70-536 говорится:

Среда выполнения оптимизирует производительность 32-битных целочисленных типов (Int32), так использовать эти типы для счетчиков и других часто доступный интеграл переменные.

Это применимо только в 32-битной среде? Int64 вступает во владение в 64-битной среде, или Int32 все еще лучший выбор?

Answer 1

Это забавный способ выразить это. Время выполнения не имеет к этому никакого отношения. ЦП предназначен для обработки 32-разрядных целых чисел, поэтому они наиболее эффективны в использовании.

В 64-битной среде это снова зависит от процессора. Тем не менее, по крайней мере на процессорах x86 (которые, насколько мне известно, это единственное место, где работает .NET), 32-разрядные целые числа по-прежнему используются по умолчанию. Регистры были просто расширены, чтобы они могли соответствовать 64-битному значению. Но 32 по-прежнему по умолчанию.

Поэтому предпочитайте 32-битные целые, даже в 64-битном режиме.

Редактировать:"default", вероятно, не то слово. Процессор просто поддерживает несколько инструкций, которые определяют, какие типы данных он может обрабатывать, а какие - нет. Там нет "по умолчанию" там. Однако обычно существует объем данных, который ЦП предназначен для эффективной обработки. А на x86 в 32- и 64-битном режиме это 32-битные целые числа. 64-битные значения, как правило, не дороже, но они означают более длинные инструкции. Я также считаю, что, по крайней мере, 64-разрядные процессоры Pentium 4 были значительно медленнее при 64-разрядных операциях, хотя на последних процессорах это не должно вызывать проблем. (Но размер инструкции все еще может быть)

Меньше, чем 32-битные значения, несколько удивительнее. Да, для передачи данных требуется меньше данных, и это хорошо, но процессор по-прежнему захватывает 32 байта за раз. Это означает, что он должен маскировать часть значения, поэтому они становятся еще медленнее.

Answer 2

Скотт Хансельман опубликовал в своем блоге статью, в которой рассматриваются различия между 32- и 64-битным управляемым кодом. Подводя итог, можно сказать, что только указатели меняют размер, целые числа по-прежнему 32 бита.

Вы можете найти пост здесь .

Answer 3

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 (woohoo, еще один префикс инструкции x86:)).

Answer 4

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

И вопреки тому, что могут сказать другие люди в этой ветке, пока вы не измерите выгоду от такой мелочи, как эта, это будет только в виде получаемой выгоды.

Answer 5

32-разрядный процессор быстрее обрабатывает 32-разрядные целые числа. 64-битный обрабатывает 64-битные целые быстрее; просто подумайте - вам нужно либо постоянно сдвигать биты на 32 бита, либо тратить 32 бита на каждые 32 бита, что, по сути, аналогично использованию 64-битной переменной без преимуществ 64-битной переменной. Другой вариант - встроить в ЦП дополнительную схему, так что переключение не потребуется, но очевидно, что это увеличит производственные затраты. Это то же самое для 32-битных процессоров, обрабатывающих 16-битные или 8-битные переменные.

Я не уверен, но я не удивлюсь, если бы 64-битный вариант .NET Framework был немного более оптимизирован для использования long - но это всего лишь предположение с моей стороны.