Оптимизировал ли компилятор виртуальный вызов?

000000013F4241DA  mov     rax,qword ptr [rsp+0F8h] //load "this" into rax
000000013F4241E2  mov     rax,qword ptr [rax]      //load vtable pointer
000000013F4241E5  mov     rcx,qword ptr [rsp+0F8h] //load "this" into rcx
000000013F4241ED  call    qword ptr [rax+8]        //call second entry in vtable?

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

Компилятор не сможет встроить виртуальный вызов, потому что да, он не сможет знать, какой объект d1 или d2 будет использоваться, поэтому допускает два возможных встроенных результата. Кроме того, в качестве виртуального вызова могут возникнуть дополнительные накладные расходы на поиск в vtable.

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

if(__rdtsc() & 1 != 0){
    for(unsigned long long i =0; i<9000000000; ++i){
        sum += d1[0].process2();
    }
}
else{
    for(unsigned long long i =0; i<9000000000; ++i){
        sum += d2[0].process2();
    }
}

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

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

Редактировать в ответ на user997112 ниже: Статический полиморфизм не работает точно для ситуации, описанной выше, но может быть использован для немного упрощения моего примера, но поместив цикл for в функцию:

void iterate_a_bunch( Parent<Child> &f )
{
    for(unsigned long long i =0; i<9000000000; ++i){
      f.process2();
    }
}

Эта функция будет компилироваться дважды, один раз для Child1 и один раз для Child2, что приведет к увеличению размера кода, но потенциально увеличит время выполнения.

Я провел эксперимент с g++, и с -O3 он выглядит оптимизированным. Однако я должен сказать, что оптимизация выглядит точно так же, как предлагает dvntehn00bz в своем ответе.

400860:       48 8b 45 00             mov    0x0(%rbp),%rax
400864:       48 89 ef                mov    %rbp,%rdi
400867:       ff 50 10                callq  *0x10(%rax)
40086a:       48 83 eb 01             sub    $0x1,%rbx
40086e:       75 f0                   jne    400860 <main+0x40>

Весь код состоит из двух циклов, полностью автоматически.

P.S. Конечно, ваши классы, вероятно, намного сложнее, чем моя тонкая версия, поэтому оптимизация, безусловно, намного проще для компилятора.