Модуль против оператора if в цикле

Question

Модуль против оператора if в цикле

0

У меня такой цикл:

for(i = 0; i < arrayLength; i++)
{
    result[i / 8] = SETBIT(result[i / 8], ++(*bitIndex), array[i]);
    *bitIndex %= 8;
}

Интересно, что лучше, с точки зрения производительности, если я использую вышеупомянутый стиль или этот стиль:

for(i = 0; i < arrayLength; i++)
{
    result[i / 8] = SETBIT(result[i / 8], ++(*bitIndex), array[i]);
    if(*bitIndex == 8) *bitIndex = 0;
}

Это в C, составленном с помощью GCC, объяснение также будет оценено.

благодаря

shoham 12 авг. 2014, в 14:07

Источник

5

Измерить. Оптимизация. Измерить. Любой ответ на этот вопрос будет зависеть от версии компилятора и его настроек оптимизации. И следующий выпуск может сделать ответ недействительным.
DevSolar 12 авг. 2014, в 11:27
0

и вместо деления на 8 вы можете использовать: i >> 3; он не медленнее, чем i / 8, но может быть быстрее в зависимости от параметров компилятора и т. д.
glezmen 12 авг. 2014, в 11:28
0

Вы также можете попробовать *bitIndex &= 7;
mch 12 авг. 2014, в 11:28
6

... и если вы не знаете, что у вас есть проблемы с производительностью из-за этой самой строки, вам все равно следует выбрать наиболее читаемый вариант.
DevSolar 12 авг. 2014, в 11:29
0

В первую очередь результат [i / 8] уже плох. Вы будете переназначать значение одного и того же индекса много раз, потому что 1/8 = 0; 2/8 = 0; 3/8 = 0
Kirilodius 12 авг. 2014, в 11:33
0

@Kirilodius Читайте остальную часть этой строки тоже. Предполагается установить следующий бит в том же байте.
The Paramagnetic Croissant 12 авг. 2014, в 11:33
1

@glezmen, 8 - константа, поэтому компилятор должен знать, что i/8 и i>>3 эквивалентны (для положительных значений), поэтому, если он еще не сгенерировал оптимальный код, получите лучший компилятор, не запутывайте код.
Jonathan Wakely 12 авг. 2014, в 11:41
0

@The Парамагнитный круассан Так что это даже стоит, потому что вы должны избегать этого переиндексации. Мы можем видеть часть метода, которая просто устанавливает значение в result [index] и только array [i] действительно важна здесь. Так это должно выглядеть следующим образом: size_t array_index = 0; for (size_t r_index = 0; r_index < r_size; ++r_index){ array_element_type value = 0; for (size_t bit_index = 0; bit_index < 8 && array_index < array_size; ++bit_index, ++array_index){ value = SETBIT(value , bit_index, array[array_index]); } result[r_index] = value; }
Kirilodius 12 авг. 2014, в 11:59

Показать ещё 6 комментариев

Теги:

c++

c

3 ответа

5

Нет смысла говорить об оптимизации...

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

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

for(i = 0; i < arrayLength; i++)
{
    (*bitIndex)++;
    SETBIT(&result[i / 8], *bitIndex, array[i]);
    *bitIndex %= 8;
}

Вероятно, это даст тот же бинарный исполняемый файл, что и у вас, + - несколько тиков процессора.

Lundin 12 авг. 2014, в 09:30

0

Вы не говорите, почему bitIndex - это указатель. Но, предполагая, что bitIndex является параметром функции, содержащей данный цикл, я бы вытащил *bitIndex материал из цикла, так что:

  unsigned bi = *bitIndex ;

  for(i = 0 ; i < arrayLength ; i++)
    {
      result[i / 8] = SETBIT(&result[i / 8], ++bi, array[i]) ;
      bi %= 8 ;
    } ;

   *bitIndex = bi ;

[Я предполагаю, что ++bi правильный, и что SETBIT() требует 1..8, где bi равно 0..7.]

Как отмечалось в других местах, компилятор имеет % 8 на завтрак и заменяет его на & 0x7 (для неподписанных, но не для подписанных). С помощью gcc -O2 выше выведен цикл из 48 байтов кода (15 команд). Скрипт с *bitIndex в цикле составлял 50 байтов кода (16 команд), включая чтение и две записи *bitIndex.

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

Если bitIndex является указателем на локальную переменную, тогда компилятор будет вытаскивать значение в регистр на протяжении всего цикла, поэтому он считает, что это стоит того!

user3793679 12 авг. 2014, в 20:32

Ещё вопросы

Измерить. Оптимизация. Измерить. Любой ответ на этот вопрос будет зависеть от версии компилятора и его настроек оптимизации. И следующий выпуск может сделать ответ недействительным.
и вместо деления на 8 вы можете использовать: i >> 3; он не медленнее, чем i / 8, но может быть быстрее в зависимости от параметров компилятора и т. д.
Вы также можете попробовать *bitIndex &= 7;
... и если вы не знаете, что у вас есть проблемы с производительностью из-за этой самой строки, вам все равно следует выбрать наиболее читаемый вариант.
В первую очередь результат [i / 8] уже плох. Вы будете переназначать значение одного и того же индекса много раз, потому что 1/8 = 0; 2/8 = 0; 3/8 = 0
@Kirilodius Читайте остальную часть этой строки тоже. Предполагается установить следующий бит в том же байте.
@glezmen, 8 - константа, поэтому компилятор должен знать, что i/8 и i>>3 эквивалентны (для положительных значений), поэтому, если он еще не сгенерировал оптимальный код, получите лучший компилятор, не запутывайте код.
@The Парамагнитный круассан Так что это даже стоит, потому что вы должны избегать этого переиндексации. Мы можем видеть часть метода, которая просто устанавливает значение в result [index] и только array [i] действительно важна здесь. Так это должно выглядеть следующим образом: size_t array_index = 0; for (size_t r_index = 0; r_index < r_size; ++r_index){ array_element_type value = 0; for (size_t bit_index = 0; bit_index < 8 && array_index < array_size; ++bit_index, ++array_index){ value = SETBIT(value , bit_index, array[array_index]); } result[r_index] = value; }

jbutler483 · Accepted Answer · 2014-08-12T08-57-00.000Z

Честно говоря, между ними будет только часть второй разницы. Но я считаю, что первая была бы ТАКЖЕ лучше для простого стиля READING. Тем не менее, этот вопрос ссылается на производительность, в которой я все еще думаю, что у первого будет край EVER SO SLIGHT для того, что компилятор читает/вычисляет меньше информации.