Actually GCC does not help reduce branch misprediction rate on modern
X86 processors.
Reducing branch taken rate is more important.
Related discussion: https://gcc.gnu.org/ml/gcc/2014-12/msg0.html
Yuan
2015-01-13 22:13 GMT+08:00 :
> Depending on what the processor hardware can do, the data y
Thank you for the explanation!
I tried the following simple code:
int test(int k)
{
int x = 0;
for (int i = 0; i < k; ++i)
x += i;
return x;
}
It was compiled (-O2) to something like:
int test(int k)
{
if (k == 0) goto ret0;
int x = 0;
int i = 0;
loop:
x += i;
i += 1;
if (i
> On Jan 13, 2015, at 7:44 AM, Alexander Monakov wrote:
>
> On Tue, 13 Jan 2015, Pengfei Yuan wrote:
>> I use perf with rbf88:k,rff88:k events (Haswell specific) to profile
>> the taken rate of conditional branches in the kernel. Here are the
>> results:
> [...]
>>
>> The results are very stran
On Tue, 13 Jan 2015, Pengfei Yuan wrote:
> I use perf with rbf88:k,rff88:k events (Haswell specific) to profile
> the taken rate of conditional branches in the kernel. Here are the
> results:
[...]
>
> The results are very strange because all the taken rates are greater
> than 50%. Why not reverse
Hi,
I have analyzed the branch taken rate of the Linux kernel compiled
with GCC (using localyesconfig from Debian config) and found something
strange.
Hardware: Intel Core i7-4770, 32G RAM, 10GbE
Software: Linux 3.16.7, GCC 4.9.3 20121201, Debian sid
I use perf with rbf88:k,rff88:k events (Haswe