Branch Misses

How bad do branch misses hurt a programs performance? In C and Java?

for example how big of an impact would :


int shitinanus()
{
    int val = getanus();
    if(val != 0)
        return ANALTONIGHT;
    return ALONETONIGHT;
}

be knowing that val will most likely be 0 99% of the time compared to the below function


int shitinanus()
{
    int val = getanus();
    if(val == 0)
        return ALONETONIGHT;
    return ANALTONIGHT;
}

>>6

ARM   Cortex-A9:         0.2875 MIPS/MHz/thread
SPARC Sun UltraSPARC II: 0.7 MIPS/MHz/thread
MIPS  ICT Loongson 3A:   0.72 MIPS/MHz/thread
POWER IBM POWER7:        0.76 MIPS/MHz/thread
IA64  Itanium 2:         0.93 MIPS/MHz/thread
x86   AMD K5:            0.92 MIPS/MHz/thread
x86   Intel i5-2400:     1.24 MIPS/MHz/thread
WHERE IS YOUR RISC GOD NOW?

>>126
x86   Intel Pentium 4  0.447 MIPS/MHz/thread
When a company has as many orders of magnitude of dollars more than their competitors as Intel does, they could make any CPU architecture run fast. If /prog/ had 100 times more money than Intel, /prog/ could make a 10 THz Brainfuck CPU and then buy out all of the Intel fabs (like Intel did to DEC/COMPAQ and HP). Who needs multiplication instructions when you have 300 million transistors for ``BrainFuckFusion'' to analyze Brainfuck loops?

>brainfuck chip
>WANT

>>127
Did you notice the AMD chip there? AMD has nowhere near the amount of money Intel does. And yet...
AMD Athlon 64 X2 (K8): 0.90 MIPS/MHz/thread

There's also this dark horse:
MCST Elbrus-3S: 1.25 MIPS/MHz/thread

which is apparently "VLIW" but also "x86 compatible".

>>129
``MIPS/MHz'' is an absolutely meaningless statement. What processor are these ``MIPS'' measured for? What is considered an ``instruction''? Are all ``instructions'' weighted equally? Are page faults and cache misses taken into account? Is the CPU run in 32-bit or 64-bit mode (if applicable)?
MCST Elbrus-3S (1891WM5AyA) CPU, 500 MHz, 218M transistors, 90 nm, 9-metal layer, 142 mm2. Power: 13-20W.
Power usage is also important. This CPU is much slower than a 1.6 GHz ARM Cortex which uses less than two watts.

>>129
This measurement would make sense only if the object code was identical on all processors. Otherwise your ``MIPS/MHz'' is saying more about the compiler's optimizations than it is about the CPUs it runs on.

>>130,131
It's a benchmark of total throughput per clock. "MIPS" is not a good term for this, they should call it 7marks or something like that. If you read the fine print at the bottom you'll see that the Intel Core 2 is taken as a reference at 1MIPS/MHz/thread. Then more efficient than it would be >1, less would be <1.

The best RISC one there is the POWER7 at 0.76 MIPS/MHz/thread, and it's not exactly power (lol) efficient either -- 200W TDP!

I've been saying this for years: CISC is going to have IPC and total throughput advantage. You can pump the RISCs to go really fast but then you're limited by the less dense code (more cache misses) and physical limits like power dissipation. In comparison a CISC won't have as many instructions and this makes for less cache misses and lower memory bandwidth, sort of like having compressed instructions in memory and decompressing them in the on-die decoder. Intel still has a lot of improvement they can do with x86 microarchitecture optimization like moving more instructions out of microcode, they just haven't seen the need to do it yet. But as memory bandwidth becomes the limiting factor for throughput it is clear that CISC-like designs are coming back and going to be the future.

check 'em

I've been giving some branch to your missuz.

What about MIPS/watt?

>>1
>2012
>Shit in Anus

>>132
thumb instruction set
checkmate, faggot

>>137
http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf

Thumb is a step in the right direction, but it's still more limited than x86. It's missing things like divide/multiply and generalised addressing modes.

This is why JIT/self-modifying code is the future.

>>139
only if it's javascript v8

anything else is just a dead end, not to mention completely incompetent