Изменяет ли это производительность, чтобы использовать не-int счетчик в цикле?

Question

Мне просто любопытно, и я нигде не могу найти ответ. Обычно мы используем целое число для счетчика в цикле, например, в C / C ++:

for (int i=0; i<100; ++i)

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

Answer 1

Вероятно, использование «натурального» целочисленного размера для платформы обеспечит наилучшую производительность. В C ++ это обычно int. Однако разница, скорее всего, будет небольшой, и вряд ли вы обнаружите, что это узкое место в производительности.

Answer 2

Зависит от архитектуры. На PowerPC обычно используется значительное снижение производительности при использовании чего-либо, кроме int (или любого другого размера слова) - например, не используйте short или char. Float тоже прав.

Вы должны рассчитать время для вашей конкретной архитектуры, потому что она варьируется, но в моих тестовых примерах было использовано ~ 20% замедление от использования short вместо int.

Answer 3

Это не совсем ответ. Я просто изучаю, что Crashworks сказал о PowerPC. Как уже отмечали другие, использование типа, который сопоставляется с собственным размером слова, должно дать самый короткий код и лучшую производительность.

$ cat loop.c
extern void bar();

void foo()
{
    int i;

    for (i = 0; i < 42; ++i)
        bar();
}

$ powerpc-eabi-gcc -S -O3 -o - loop.c
.
.
.L5:
        bl bar
        addic. 31,31,-1
        bge+ 0,.L5

С short i он отличается от int i, и, похоже, тоже не будет работать.

.L5:
        bl bar
        addi 3,31,1
        extsh 31,3
        cmpwi 7,31,41
        ble+ 7,.L5

Answer 4

Вы можете использовать любой допустимый тип, для которого вы хотите; он не должен быть целым или даже встроенным. Например, вы также можете использовать итераторы:

for( std::vector<std::string>::iterator s = myStrings.begin(); myStrings.end() != s; ++s )
{
...
}

Влияет ли это на производительность или нет, возникает вопрос о том, как реализованы используемые вами операторы. Таким образом, в приведенном выше примере это означает end (), operator! = () И operator ++ ().

Answer 5

Я не могу предоставить цитату, но я слышал, что вы часто подвергаетесь небольшому снижению производительности, используя short или char.

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

Answer 6

Теория без знака или size_t теоретически должна дать вам лучшие результаты (вау, простые люди, мы пытаемся оптимизировать для зла и против тех, кто кричит «преждевременная» чепуха. Это новая тенденция).

Тем не менее, у него есть свои недостатки, в первую очередь классические: провал.

Разработчики Google, похоже, этого не избегают, но бороться со стандартным заболеванием или надбавкой - это жалко.

Answer 7

Вероятно, не так долго, пока вы не сделаете это с float или double. Поскольку память дешевая, вам, вероятно, лучше всего использовать int.

Answer 8

Вероятно, было бы быстрее набрать быструю программу (вы уже сделали самую сложную строку) и профилировать ее, чем задавать этот вопрос здесь. : -)

FWIW, в языках, которые по умолчанию используют bignums (Python, Lisp и т. Д.), Я никогда не видел профиля, где узким местом был счетчик цикла. Проверка тега типа не так уж и дорога - максимум пара инструкций - но, вероятно, больше, чем разница между (fix) int и short int.

Answer 9

Нет, это действительно не должно влиять на производительность.

Answer 10

Если вы компилируете свою программу с оптимизацией (например, gcc -O), это не имеет значения. Компилятор выделит целочисленный регистр для значения и никогда не сохранит его в памяти или в стеке. Если ваш цикл вызывает подпрограмму, gcc выделит одну из переменных r14-r31, которую любая вызванная подпрограмма сохранит и восстановит. Поэтому используйте int, потому что это вызывает наименьшее удивление у того, кто читает ваш код.