C这个无分支的黑客实际上更快吗？

Question

I'm trying to clamp a value between -127 and 127 on a Cortex-M based microcontroller .

I have two competing functions, one uses conditionals the other uses a branchless hack I found here .

// Using conditional statements
int clamp(int val) { return ((val > 127) ? 127 : (val < -127) ? -127 : val); }

// Using branchless hacks
int clamp(int val) {
    val -= -127;
    val &= (~val) >> 31;
    val += -127;
    val -= 127;
    val &= val >> 31;
    val += 127;

    return val;
}

Now I know in some cases one of these methods might be faster than the other, and vise-versa but in general is it worth it to use the branchless technique seeing as it doesn't really matter to me which I use, they both will work just fine in my case?

A little background on the microcontroller, it's a ARM based microcontroller running at 90 MIPS with a 3 stage pipeline, fetch, decode and execute and it seems to have some sort of branch predictor but I couldn't dig up details.

Answer 1

ARM code (GCC 4.6.3 with -O3 ):

clamp1:
    mvn r3, #126
    cmp r0, r3
    movlt   r0, r3
    cmp r0, #127
    movge   r0, #127
    bx  lr

clamp2:
    add r0, r0, #127
    mvn r3, r0
    and r0, r0, r3, asr #31
    sub r0, r0, #254
    and r0, r0, r0, asr #31
    add r0, r0, #127
    bx  lr

Thumb code:

clamp1:
    mvn r3, #126
    cmp r0, r3
    it  lt
    movlt   r0, r3
    cmp r0, #127
    it  ge
    movge   r0, #127
    bx  lr

clamp2:
    adds    r0, r0, #127
    mvns    r3, r0
    and r0, r0, r3, asr #31
    subs    r0, r0, #254
    and r0, r0, r0, asr #31
    adds    r0, r0, #127
    bx  lr

Both are branchless thanks to ARM's conditional execution design. I will bet you they are essentially comparable in performance.

Answer 2

Something to realize is the the ARM and x86 architectures are very different when it comes to branch instructions. Taking a jump clears the pipeline which can result in the expediture of a number of clock cycles just to 'get back to where you were' in terms of throughput.

To quote a pdf I downloaded the other day (pg14 of http://simplemachines.it/doc/arm_inst.pdf ),

Conditional Execution

• Most instruction sets only allow branches to be executed conditionally.
• However by reusing the condition evaluation hardware, ARM effectively increases number of instructions.
• All instructions contain a condition field which determines whether the CPU will execute them.
• Non-executed instructions soak up 1 cycle. – Still have to complete cycle so as to allow fetching and decoding of following instructions.
• This removes the need for many branches, which stall the pipeline (3 cycles to refill).
• Allows very dense in-line code, without branches.
• The Time penalty of not executing several conditional instructions is frequently less than overhead of the branch or subroutine call that would otherwise be needed.

Answer 3

No. The C language doesn't have speed; That's a concept that's introduced by implementations of C. A perfectly optimal compiler would translate both of those to the same machine code.

C compilers are more likely to be able to optimise code that conforms to common styles and is well defined. The second function isn't well defined.

Those additions and subtractions could cause integer overflows. Integer overflows are undefined behaviour, so they could cause your program to malfunction. Optimistically, your hardware might implement wrapping or saturation. Slightly less optimistically, your OS or compiler might implement signals or trap representations for integer overflows. Detecting integer overflows might affect the percieved performance of modifying a variable. The worst case is that your program loses it's integrity.

The & and >> operators have implementation-defined aspects for signed types. They may result in a negative-zero, which is an example of a trap representation. Using a trap representation is undefined behaviour, so your program could lose it's integrity.

Perhaps your OS or compiler implements parity bit checks for int objects. In this case, try to imagine recalculating the parity bits every time a variable changes and verifying the parity bits every time a variable is read. If a parity check fails, your program could lose it's integrity.

Use the first function. At least it's well defined. If your program appears to be running slow, optimising this code probably won't speed your program up significantly; Use a profiler to find more significant optimisations, use a more optimal OS or compiler or buy faster hardware.