Прогнозирование отрасли бесплатно?

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

1. Допустим, у нас есть это:

x += a; // let's assume they are both declared earlier as simple ints
if (flag)
do A  // let's assume A is not the same as B
else
do B  // and of course B is different than A

2. По сравнению с этим:

if (flag)
{
x += a
do A
}
else
{
x += a
do B
}

Если предположить, A а также B полностью различаются в терминах инструкций конвейера (выборка, декодирование, выполнение и т. д.):

1. Второй подход будет быстрее?

2. Достаточно ли умены процессоры, чтобы сказать, что независимо от того, что это за флаг, следующая инструкция одна и та же (поэтому им не придется отбрасывать этапы конвейера для него из-за предсказания пропадания ветки)?

Замечания:

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

РЕДАКТИРОВАТЬ:
Я провел некоторые исследования, и у меня есть хорошие результаты. Как бы вы объяснили это поведение? Извините за последнее изменение, но, насколько я вижу, у меня были некоторые проблемы с кэшем, надеюсь, это более точные результаты и примеры кода.

Вот код, скомпилированный с gcc версии 4.8.2 (Ubuntu 4.8.2-19ubuntu1) с использованием -O3.

Случай 1.

#include <stdio.h>

extern int * cache;
extern bool * b;
extern int * x;
extern int * a;
extern unsigned long * loop;

extern void A();
extern void B();

int main()
{
for (unsigned long i = 0; i < *loop; ++i)
{
++*cache;

*x += *a;

if (*b)
{
A();
}
else
{
B();
}
}

delete b;
delete x;
delete a;
delete loop;
delete cache;

return 0;
}

int * cache = new int(0);
bool * b = new bool(true);
int * x = new int(0);
int * a = new int(0);
unsigned long * loop = new unsigned long(0x0ffffffe);

void A() { --*x; *b = false; }
void B() { ++*x; *b = true; }

Дело 2

#include <stdio.h>

extern int * cache;
extern bool * b;
extern int * x;
extern int * a;
extern unsigned long * loop;

extern void A();
extern void B();

int main()
{
for (unsigned long i = 0; i < *loop; ++i)
{
++*cache;

if (*b)
{
*x += *a;
A();
}
else
{
*x += *a;
B();
}
}

delete b;
delete x;
delete a;
delete loop;
delete cache;

return 0;
}

int * cache = new int(0);
bool * b = new bool(true);
int * x = new int(0);
int * a = new int(0);
unsigned long * loop = new unsigned long(0x0ffffffe);

void A() { --*x; *b = false; }
void B() { ++*x; *b = true; }

Существует почти незаметная разница между версиями -O3 обоих подходов, но без -O3 второй случай работает немного быстрее, по крайней мере, на моей машине.
Я тестировал без -O3 и с циклом = 0xfffffffe.
Лучшие времена:
alin @ ubuntu: ~ / Desktop $ time ./1

реальный 0m20.231s
пользователь 0m20.224s
sys 0m0.020s

alin @ ubuntu: ~ / Desktop $ time ./2

реальный 0m19.932s
пользователь 0m19.890s
sys 0m0.060s