C++ Для оптимизации циклов для виртуальной машины

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

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

Учитывая это, я выберу конкретный компилятор (gcc) и общую архитектуру (x86) и отвечу в этом контексте. Детали будут немного отличаться для других вариантов, но я ожидаю, что общие черты будут одинаковыми для любой приличной комбинации компилятора и оборудования.

Вопрос 1

Место декларации значения не имеет. Само объявление даже не превращается в код - это только определение и использование, которое генерирует код.

Например, рассмотрим два варианта простого цикла ниже (внешний метод sink() нужен только для того, чтобы избежать оптимизации способа присваивания a):

Объявление внутри цикла

int func(int* num) {
  for (unsigned int i=0; i<100; i++) {
    int a = *num + *num;
    sink(a);
    sink(a);
  }
}

Объявление вне цикла

int func(int* num) {
  int a;
  for (unsigned int i=0; i<100; i++) {
    a = *num + *num;
    sink(a);
    sink(a);
  }
}

Мы можем использовать проводник компилятора godbolt, чтобы легко проверить сборку, сгенерированную для first и второй вариант. Они идентичны - вот петля:

.L2:
        mov     ebp, DWORD PTR [r12]
        add     ebx, 1
        add     ebp, ebp
        mov     edi, ebp
        call    sink(int)
        mov     edi, ebp
        call    sink(int)
        cmp     ebx, 100
        jne     .L2

По сути, объявление не создает никакого кода — это делает только присваивание.

вопрос 2

Здесь важно отметить, что на аппаратном уровне нет таких инструкций, как «прервать» или «продолжить». На самом деле у вас есть только переходы, условные или нет, которые в основном являются переходами. И break, и continue будут преобразованы в прыжки. В вашем случае break внутри переключателя, где break является последним оператором в цикле, и continue внутри переключателя имеют точно такой же эффект, поэтому я ожидаю компилируются они одинаково, но давайте проверим.

Давайте используем этот тестовый пример:

int func(unsigned int num, int iters) {
  for (; iters > 0; iters--) {
    switch (num) {
      case 0:
        sinka();
        break;
      case 1:
        sinkb();
        break;
      case 2:
        sinkc();
        break;
      case 3:
        sinkd();
        break;
      case 4:
        sinkd();
        break;
    }
  }
}

Он использует разрыв для существования случая. Вот выходные данные Godbolt для gcc 4.4.7 для x86, игнорируя пролог функции:

.L13:
        cmp     ebp, 4
        ja      .L3
        jmp     [QWORD PTR [r13+r12*8]] # indirect jump
.L9:
        .quad   .L4
        .quad   .L5
        .quad   .L6
        .quad   .L7
        .quad   .L8
.L4:
        call    sinka()
        jmp     .L3
.L5:
        call    sinkb()
        jmp     .L3
.L6
        call    sinkc()
        jmp     .L3
.L7
        call    sinkd()
        jmp     .L3
.L8
        call    sinkd()
.L3:
        sub     ebx, 1
        test    ebx, ebx
        jg      .L13

Здесь компилятор выбрал подход таблицы переходов. Значение num используется для поиска адреса перехода (таблица представляет собой набор директив .quad), а затем выполняется непрямой переход к одной из меток с L4 по L8. Разрывы меняются на jmp .L3, которые выполняют логику цикла.

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

Давайте попробуем тот же пример, но с заменой каждого break на continue:

int func(unsigned int num, int iters) {
  for (; iters > 0; iters--) {
    switch (num) {
      case 0:
        sinka();
        continue;
... [16 lines omitted] ...
    }
  }
}

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

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