MIPS bne beq Computer Organization and Design - if-statement

Question

So, I'll quote my textbook(Computer Organization and Design) and then I'll ask my question:
Compiling if-then-else into Conditional branches
In the following code segment, f, g, j, i and j are variables. If the five variables f through j correspond to the five registers $s0 through $s4, what is the compiled MIPS code for this C if statement?
if (i == j) f = g + h; else f = g - h;
Figure 2.9 is a flowchart of what the MIPS code should do. The first expression compares for equality, so it would seem that we would want the branch if registers are equal instruction (beq). In general, the code will be more efficient if we test for the opposite condition to branch over the code that performs the subsequent then part of the if (the label Else is defined below) and so we use the branch if registers are not equal instruction (bne):
bne $s3, $s4, Else # go to Else if i ≠ j
I've searched for a while but I couldn't find why bne would be more efficient than beq.
(I did however find that bne is sometimes recommended because it makes the code easier to understand, as the statements to be executed when the condition holds are right below the bne statement.)
So, if it would not be more efficient in general, it still could be more efficient in this particular exercise. I've thought about that, and I assumed that a branch instruction costs more time if taken, and therefore we'd want to minimize the amount of jumps (taken branches) needed. This means that, when we expect the condition to hold, we should use bne, and when we expect the condition to fail, we should use beq.
Now if we test whether $s3 equals $s4, when we have no information whatsoever about the content of those registers it's not reasonable to assume that they're likely to be equal. On the contrary, it's more likely that they're not equal, which should favour using beq instead of bne.
So, to sum up: textbook says bne is more efficient than beq, whether it's in general or just in this example is not clear, but in either case I don't understand why.

Answer 1

The efficiency is not from a direct comparison of the machine code for a bne versus beq. The text describes optimizing the over all performance by coding to shorten the most common code path.
If you assume the values are more likely to be unequal then only one instruction needs be processed when using bne, if you use beq you must perform an additional jump on failure.
The shortest path is to drop through the compare, to fail it and not jump.
from http://www.cs.gmu.edu/~setia/cs365-S02/class3.pdf:
Uncommon Case for branches
beq $18, $19, L1
else handling
jmp
replaced by
bne $18, $19, L2
success handling
end
L2:
Make the common case fast -
one instruction for most branches
Re-reading your question, I think the crux is this assumption:
"Now if we test whether $s3 equals $s4, when we have no information
whatsoever about the content of those registers, it's not reasonable
to assume that they're likely to be equal; on the contrary, it's more
likely that they're not equal, which should result in using beq
instead of bne."
This seems to be the confusion, we need to find some evidence or reason to determine which possibility is more likely, registers equal or unequal.
In this case we are examining an if-then-else. I make the assertion that we expect the if-test to pass, this is the psychology described by twalberg. The registers are unlikely to contain random values as they contain data that the programer is expecting - the result of previous operations.

Answer 2

I believe this has something to do with simplifying the compiler. In the case that you have an equality assertion, you would want to skip over the code to execute if the condition is not met. I would assume that this decision was made to use the exact same procedure in the case where you do have an else condition and not. Here's what I think. By all means, if my reasoning is wrong, please tell me! :)
Starting with the given pseudocode from OP:
if (i == j) {
f = g + h;
}
else {
f = g - h;
}
Would translate to:
bne $s3, $s4, Else
add $s0, $s1, $s2
j Exit
Else: sub $s0, $s1, $s2
Exit: ...
If you changed the C code to just perform the addition if i == j:
if (i == j) {
f = g + h;
}
The compiler would come up with something like this:
bne $s3, $s4, Exit
add $s0, $s1, $s2
Exit: ...
Now, let's think about what the compiled code would look like if we tested the assertion using beq instead. I'm guessing it would look somewhat like this:
beq $s3, $s4, Equal
j Exit
Equal:
add $s0, $s1, $s2
Exit: ...
Which seems a lot less efficient than testing with bne.
EDIT
There's also the fact that checking for inequality is faster for a CPU than checking for equality.
If you try to compare 2 32 bit numbers for equality, the CPU has to compare every single bit of that 32 bit number to make sure they are equal. If testing for non-equality, if the first bits of the 2 numbers are different, the CPU doesn't have to bother with testing any of the other bits to assert the inequality.

Answer 3

Another reason for this is that simple branch predictors usually assume that forward branches are not taken and that backwards branches are taken. This assumption gives better performance for simple loops.