Being abstract is something profoundly different from being vague … The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

• Edsger Dijkstra

Let's take a look at the snippet of code performing exponentiation:

#include <cmath>
int my_pow(int x) {
    return std::pow(x, 6);
}

It would be reasonable to expect pow(x, 6) to be expanded into something like x * x * x * x * x * x or better yet:

int my_pow(int x) {
    int x2 = x * x;
    int x4 = x2 * x2;
    return x2 * x4;
}

which reduces the number of multiplications from 5 to 3.

Unfortunately, the generated assembly comes with a couple of bad surprises:

my_pow(int):
        scvtf   d0, w0
        stp     x29, x30, [sp, -16]!
        fmov    d1, 6.0e+0
        mov     x29, sp
        bl      pow
        fcvtzs  w0, d0
        ldp     x29, x30, [sp], 16
        ret

• x has to be converted from integer to floating-point
• literal 6 is also stored as a floating-point number in d1
• less efficient floating-point version of pow is invoked, that comes with extra cost of function call overhead
• the floating-point result of pow computation stored in d0 has to be converted into return integer.

Let's compare this assembly with the one generated for the naive hand-written version:

int my_pow(int x) {
    return x * x * x * x * x * x;
}

Lo and behold we get the optimal assembly:

my_pow(int):
        mul     w1, w0, w0 ; x2 = x * x
        mul     w0, w1, w0 ; x3 = x2 * x
        mul     w0, w0, w0 ; x6 = x3 * x3
        ret

that is a little different from the version we've speculated above but still uses the optimal number of multiplications - 3. This violates the principle of least surprise and one of the aspects of zero cost abstractions promised by C++:

Optimal performance: A zero cost abstractoin ought to compile to the best implementation of the solution that someone would have written with the lower level primitives. It can’t introduce additional costs that could be avoided without the abstraction.

Rust is another popular programming language promising zero cost abstractions, so let's see how it would handle

pub fn my_pow(x: i32) -> i32 {
    x.pow(6)
}

And we've got a winner:

my_pow:                                 # @my_pow
# %bb.0:
    imull    %edi, %edi ; x2 = x * x
    movl    %edi, %eax
    imull    %edi, %eax ; x4 = x2 * x2
    imull    %edi, %eax ; x6 = x2 * x4
    retq

As such, Rust was able to inline pow invocation and generate almost optimal code that interestingly matches the approach we've discussed at the beginning of the article. It comes with an extra movl instruction that could be eliminated, but it's still a lot more efficient than the C++ version.

Moral of the story? Don't violate the principle of least surprise and either fulfill the promise of zero-abstraction or be explicit about the shenanigans that happen under the hood.