Почему целое число всегда используется как управляющая переменная в цикле for?

Часто случается, когда вы знаете, что ваш цикл никогда не будет выполняться больше, чем x раз, где x может быть представлен байтом или коротким, в основном, типом данных, меньшим, чем int.

Почему мы используем int, который занимает 32 бита (с большинством языков), когда хватит только одного байта, который составляет всего 8 бит.

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

UPDATE: Просто для уточнения. Я знаю, что скорость разумна, нет никакой разницы. Я спрашиваю о влиянии на потребление памяти.

Ответ 1

В C термин "int" определяется как наиболее эффективный целочисленный тип для текущей машины.

Обычно он совпадает с регистрами ЦП, так как он наиболее эффективен.

Использование меньшего типа целочисленного значения может привести к некоторому смещению бит или бит-маскированию на уровне ЦП, чтобы вы не получили выигрыш...

Ответ 2

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

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

Но, как всегда, используйте то, что наиболее читаемо, и сначала оценивайте/оценивать...

Ответ 3

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

Чем больше стандартный мой код, тем легче читать в будущем.

Ответ 4

Во многих случаях счетчик циклов потребляет ровно один регистр процессора. Изменение типа на 8- или 16-разрядное целое не изменяет его, поскольку регистры имеют фиксированный размер (32 бита на 32-битной платформе и т.д.).

Иногда счетчик циклов может быть помещен в ОЗУ, например. когда вы вызываете функцию из цикла. Тогда, да, вы можете потратить несколько байтов, но, как правило, этого недостаточно, чтобы беспокоиться. Хранение и загрузка счетчика циклов на самом деле может быть медленнее при использовании чего-то другого, отличного от int.

Ответ 5

В терминах Спецификация языка Java есть интересный момент, чтобы отметить использование long и double:

Для целей Java модель памяти языка программирования, однократная запись в энергонезависимую длинную или двойное значение рассматривается как два отдельные записи: по одному на каждый 32-разрядный половина. Это может привести к ситуации где поток видит первые 32 бита из 64-битного значения из одной записи и второй 32 бита из другой записи. Пишет и читает летучие длинные и двойные значения всегда являются атомарными. Пишет и читает ссылки всегда атомный, независимо от того, они реализованы как 32 или 64 бит значения. Разработчики VM поощряются чтобы избежать расщепления их 64-битных значений где возможно. Программисты рекомендуется объявлять общие 64-битные значения как изменчивые или синхронизируемые их программы правильно избегать возможные осложнения.

Ясно, что это делает использование long или double в вашей переменной цикла менее эффективной, чем int в модели памяти Java, но реализации могут отличаться по производительности.

Ответ 6

У меня возникает соблазн добавить что-то здесь, даже если это очень старый поток. Я не совсем согласен с "Я знаю, что скорость мудрая не имеет значения". В самом деле, очень часто в цикле for существует индексирование массива, например, в

for (i=0; i<len; i++) s = A[i]

Тогда, даже если ваш массив имеет размер меньше 128, вы увидите заметную разницу в скорости, если i является int или byte. Действительно, для выполнения арифметики указателя в A[i] процессор должен преобразовать ваше целое число в то, что имеет тот же размер, что и указатель. Если целое число уже имеет одинаковый размер, тогда нет преобразования, которое вызывает более быстрый код. На 64-битной машине я, похоже, на 20% ускоряюсь в программах, используя long int для индексов цикла на очень маленьком массиве вместо char (программы C/С++).