it changes, first start by exploring different instruction sets and how compilers use these instruction sets. Take openrisc 32, for example, which is undoubtedly inspired by mips, but makes conditional differences differently. For or32 there are commands for comparing and setting the flag, compare these two registers, if they are less than or equal to unsigned, then set the flag, compare these two registers, if they are equal, set the flag. Then there are two branches of the conditional branch of the branch on the flag set, and the branch on the flag. The compiler must follow one of these paths, but less than, less than or equal to, more, etc. Everyone will use the same number of instructions, the same runtime for a conditional branch, and the same runtime so as not to execute a conditional branch.
Now this will definitely be true for most branch architectures, it takes longer than the branch does not, due to the need to reset and refill the pipe. Some of them predict a branch, etc., to help with this problem.
Now some architectures can change in size, compare gpr0 and gpr1 vs compare gpr0 and the immediate number 1234, it may take a lot of instruction, you will see this a lot with x86, for example. so although both cases can be a branch if they are smaller than you code less, depending on which registers will contain values that can affect performance (I'm sure x86 does a lot of pipelining operations, a lot of caching, etc. . to compensate for these problems). Another similar example is mips and or32, where r0 is always zero, this is not a very general case, if you write to it, it does not change, it is tied to zero, so a comparison, if it is 0, MAY cost you more than a comparison, if it is equal to some other number, if an additional command or two is required to fill gpr so immediately that comparisons can happen, the worst case is to push the register onto the stack or memory to free register, to set it up immediately so that it is possible to compare.
Some architectures have conditional execution, such as a hand, to execute all the commands (not the thumb) that you can execute on each instruction, so if you have code
if(i==7) j=5; else j=9;
pseudocode for the hand will be
cmp i,#7 moveq j,#5 movne j,#7
there is no branch, so not a single conveyor pushes you directly, very quickly.
One architecture for another, if this is an interesting comparison, as mentioned, mips or 32, you need to specially execute some kind of instruction for comparison, others, such as x86, msp430 and the vast majority of alu operations, change flags, lever, etc. if you tell him to change the flags, otherwise, as shown above. so
while(--len) { //do something }
loop, subtraction 1 also sets flags, if the material in the loop was simple enough, you could make everything conditional, so you save separate comparison and branching commands, and you save the penalty in the pipeline. Mips solves this a bit, comparing and the branch is one instruction, and they execute one instruction after the branch to save a little in the pipe.
The general answer is that you will not see the difference, the number of instructions, the execution time, etc. same for different conditional expressions. special cases, such as small immediate actions and large immediate actions, etc., can have an effect for corner cases, or the compiler can just do things differently depending on what kind of comparison you are doing. If you try to rewrite your algorithm to give the same answer, but use less than instead of more and equal, you could change the code enough to get a different stream of commands. Similarly, if you run a performance test that is too simple, the compiler can / will optimize the full comparison and simply generate results, which may vary depending on your test code causing another execution. The key to all this is to parse what you want to compare and see how the instructions differ. This will tell you whether any differences in execution should be expected.