Будет ли компилятор разворачивать этот цикл?

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

    Vector<int, 16> a, b;
    Vector<int, 65536> c, d;

    asm("xxx"); // marker
    a.Add(b);
    asm("yyy"); // marker
    c.Add(d);
    asm("zzz"); // marker

Теперь скомпилируйте

gcc -O3 1.cc -S -o 1.s

И увидеть дизассем

    xxx
# 0 "" 2
#NO_APP
    movdqa  524248(%rsp), %xmm0
    leaq    524248(%rsp), %rsi
    paddd   524184(%rsp), %xmm0
    movdqa  %xmm0, 524248(%rsp)
    movdqa  524264(%rsp), %xmm0
    paddd   524200(%rsp), %xmm0
    movdqa  %xmm0, 524264(%rsp)
    movdqa  524280(%rsp), %xmm0
    paddd   524216(%rsp), %xmm0
    movdqa  %xmm0, 524280(%rsp)
    movdqa  524296(%rsp), %xmm0
    paddd   524232(%rsp), %xmm0
    movdqa  %xmm0, 524296(%rsp)
#APP
# 36 "1.cc" 1
    yyy
# 0 "" 2
#NO_APP
    leaq    262040(%rsp), %rdx
    leaq    -104(%rsp), %rcx
    xorl    %eax, %eax
    .p2align 4,,10
    .p2align 3
.L2:
    movdqa  (%rcx,%rax), %xmm0
    paddd   (%rdx,%rax), %xmm0
    movdqa  %xmm0, (%rdx,%rax)
    addq    $16, %rax
    cmpq    $262144, %rax
    jne .L2
#APP
# 38 "1.cc" 1
    zzz

Как видите, первая петля была достаточно маленькой, чтобы ее можно было развернуть. Второй — петля.

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

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

Третье: современные компиляторы могут даже автоматически векторизовать цикл, что даже лучше, чем разворачивание.

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

Цикл можно развернуть, используя рекурсивное создание экземпляров шаблона. Это может быть или не быть быстрее в вашей реализации C++.

Я немного подкорректировал ваш пример, чтобы он компилировался.

typedef unsigned u32; // or something similar

template <typename T, u32 size>
class Vector
{
  // need to use an inner class, because member templates of an 
  // unspecialized template cannot be explicitly specialized.
  template<typename Vec, u32 index>
  struct Inner
  {
    static void add(const Vec& a, const Vec& b)
    {
      a.values[index] = b.values[index];
      // triggers recursive instantiation of Inner 
      Inner<Vec, index-1>::add(a,b);
    }
  };
  // this specialization terminates the recursion
  template<typename Vec>
  struct Inner<Vec, 0>
  {
    static void add(const Vec& a, const Vec& b)
    {
      a.values[0] = b.values[0];
    }
  };

public:

    // PS! this function should probably take a 
    // _const_ Vector, because the argument is not modified
    // Various functions for mathematical operations. 
    // The functions take in a Vector<T, size>.
    // Example:
    void add(Vector<T, size>& vec)
    {
      Inner<Vector, size-1>::add(*this, vec);
    }

    T   values[size];
};

Единственный способ понять это — попробовать на собственном компиляторе с собственными параметрами оптимизации. Создайте один тестовый файл с вашим кодом "разворачивается" test.cpp:

#include "myclass.hpp"

void doSomething(Vector<double, 3>& a, Vector<double, 3>& b) {
    a.add( b );
}

затем фрагмент кода ссылки reference.cpp:

#include "myclass.hpp"

void doSomething(Vector<double, 3>& a, Vector<double, 3>& b) {
    a[0] += b[0];
    a[1] += b[1];
    a[2] += b[2];
}

а теперь используйте GCC, чтобы скомпилировать их и выплюнуть только сборку:

for x in *.cpp; do  g++ -c "$x" -Wall -Wextra -O2 -S -o "out/$x.s"; done

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

Во-первых, совсем не факт, что развертывание цикла принесет пользу.

Единственный возможный ответ на ваш вопрос: «это зависит» (от флагов компилятора, от значения size и т. д.).

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

Многие компиляторы будут разворачивать этот цикл, не зная, будет ли это делать «компилятор», о котором вы говорите. В мире существует не один компилятор.

Если вы хотите гарантировать, что он развернут, то TMP (с встраиванием) может это сделать. (На самом деле это одно из самых простых применений TMP, часто используемое в качестве примера метапрограммирования).