C 功能优化

Question

I have a function that looks about like so, constants a1-e8 (double precision floats) are in the code let's say either hardcoded or as #defined. The function accepts doubles within the range of -1.0 to 1.0 and needs to be split in quarters as shown.

Are there any other code optimizations I can make to increase runtime performance before assembly language optimization? I tried making an x2 to hold x*x and made the e constants multiply by x2*x2 but it actually slowed down performance. I also tried seeing if I could cast a copy of x as an integer and use a switch statement but it also slowed down performance.

double operation(double x) {
    if (x <= -0.75 && x >= -1.0) {
        return a1 + b1*x + c1*x*x + d1*x*x*x + e1*x*x*x*x;
    }
    else if (x <= -0.5) {
        return a2 + b2*x - c2*x*x - d2*x*x*x - e2*x*x*x*x;
    }
    else if (x <= -0.25) {
        return a3 - b3*x - c3*x*x - d3*x*x*x - e3*x*x*x*x;
    }
    else if (x <= 0.0) {
        return a4 - b4*x - c4*x*x - d4*x*x*x + e4*x*x*x*x;
    }
    else if (x <= 0.25) {
        return a5 + b5*x - c5*x*x + d5*x*x*x + e5*x*x*x*x;
    }
    else if (x <= 0.5) {
        return a6 + b6*x - c6*x*x + d6*x*x*x - e6*x*x*x*x;
    }
    else if (x <= 0.75) {
        return a7 - b7*x - c7*x*x + d7*x*x*x - e7*x*x*x*x;
    }
    else if (x <= 1.0) {
        return a8 - b8*x + c8*x*x - d8*x*x*x + f8*x*x*x*x;
    }
    return 0.0;
}

Answer 1

Other than the using compile flag (-Ofast on Linux/Mint19), which will speedup performance by about 2.5 (100,000,000 calls, mostly within the range), there are few minor adjustment that can help:

• Replacing if with lookups. see below. Reduce wasting time to find the right case. Coefficient has been adjusted +/- based on addition/subtraction of the formula.

This will provide +25% speed.

Original code: un-optimized: 2.154 Optimized with -Ofast: 0.678 Modified code, -Ofast: 0.581

double operation(double x) {
    static double aa[] = { a1, a2, a3, a4, a5, a6, a7, a8 } ;
    static double bb[] = { b1, b2, -b3, -b4, b5, b6, -b7, -b8 } ;
    static double cc[] = { c1, -c2, -c3, -c4, -c5, -c6, -c7, c8 } ;
    static double dd[] = { d1, -d2, -d3, -d4, d5, d6, d7, -d8 } ;
    static double ee[] = { e1, -e2, -e3, e4, e5, -e6, -e7, e8 } ;


    if (x < -1.0 || x > 1.0) {
        return 0 ;
    }
    int p = x*4 + 4 ;
//    if ( p < 0 ) p = 1;
    return aa[p] + bb[p]*x + cc[p]*x*x + dd[p]*x*x*x + ee[p]*x*x*x*x;
}

Note: I believe original code has a minor. It will use the coefficient for (x<-0.5) for any negative value <-1. I believe intention was that anything outside -1..+1 should return 0.

Answer 2

Are there any other code optimizations I can make to increase runtime performance before assembly language optimization?

Rearranging the comparisons so that you're basically doing a binary search for the right case rather than a linear one speeds things up quite a bit:

double op2(double x) {
    if (x <= 0) {
        if (x <= -0.5) {
            if (x <= -0.75 && x >= -1.0) {
                return a1 + b1*x + c1*x*x + d1*x*x*x + e1*x*x*x*x;
            }
            return a2 + b2*x - c2*x*x - d2*x*x*x - e2*x*x*x*x;
        }
        else {
            if (x <= -0.25) {
                return a3 - b3*x - c3*x*x - d3*x*x*x - e3*x*x*x*x;
            }
            return a4 - b4*x - c4*x*x - d4*x*x*x + e4*x*x*x*x;
        }
    }
    else {
        if (x <= 0.5) {
            if (x <= 0.25) {
                return a5 + b5*x - c5*x*x + d5*x*x*x + e5*x*x*x*x;
            }
            return a6 + b6*x - c6*x*x + d6*x*x*x - e6*x*x*x*x;
        }
        else {
            if (x <= 0.75) {
                return a7 - b7*x - c7*x*x + d7*x*x*x - e7*x*x*x*x;
            }
            else if (x <= 1.0) {
                return a8 - b8*x + c8*x*x - d8*x*x*x + e8*x*x*x*x;
            }
        }
    }
    return 0.0;
}

I tested this by calling the original version ( op1 ) and my version ( op2 ) both inside the same loop with the same random input in the range [-1.0, 1.0]. Both functions return the same value. Profiling the code over a hundred million iterations of the loop, I got the following results:

So, the op2 version is a little less than twice as fast as the original.

---

Update:

I also tested a version that maps the input to an integer and then switches on that. That only works because the intervals are all the same size, so whereas the approach in op2 could work for arbitrary intervals, this one won't. To do the mapping I add 1 to the input, to shift the input range to [0, 2.0], and then multiply by 4, to expand the range to [0, 8.0]. Then I convert it to int so that we can switch on it. The nice thing about a switch statement with a number of consecutive values is that the compiler can implement it as a jump table, which makes it very fast. The cost is that extra floating point multiplication. Here's the function:

double op3(double x) {
    int c = (int)((x + 1) * 4);    // mapping from double to int
    switch (c) {
        case 0: {
            return a1 + b1*x + c1*x*x + d1*x*x*x + e1*x*x*x*x;
        }
        case 1: {
            return a2 + b2*x - c2*x*x - d2*x*x*x - e2*x*x*x*x;
        }
        case 2: {
            return a3 - b3*x - c3*x*x - d3*x*x*x - e3*x*x*x*x;
        }
        case 3: {
            return a4 - b4*x - c4*x*x - d4*x*x*x + e4*x*x*x*x;
        }
        case 4: {
            return a5 + b5*x - c5*x*x + d5*x*x*x + e5*x*x*x*x;
        }
        case 5: {
            return a6 + b6*x - c6*x*x + d6*x*x*x - e6*x*x*x*x;
        }
        case 6: {
            return a7 - b7*x - c7*x*x + d7*x*x*x - e7*x*x*x*x;
        }
        case 7: {
            return a8 - b8*x + c8*x*x - d8*x*x*x + e8*x*x*x*x;
         }
        default: {
            return 0.0;
        }
    }
}

And the results:

So, op3 is a lot faster than the original op1 , but op2 is still the winner in this case. If you had more cases, though, I think you'd eventually reach a point where the cost of mapping the input to an integer is less than the cost of the comparisons in op2 .

Looking at the three functions, you can see that the complexity of the op1 approach is O(n), where n is the number of intervals. The op2 approach is O(log n), since there are log n levels of comparison needed for n intervals. And the op3 approach is O(1): once you map the input to an interval, the switch statement can use a jump table to find the right case in constant time.

Answer 3

using clang on a vanilla mac:

double dcos(double a, double b, double c, double d, double e, double x) {
        return a + b * x + c * x * x + d * x * x * x + e * x * x * x * x;
}

generated 10 mulsd, 4 addsd whereas:

double dcos(double a, double b, double c, double d, double e, double x) {
        double x2 = x * x;
        return a + b * x + c * x2 + d * x * x2 + e * x2 * x2;
}

generated 7 mulsd, 3 addsd. It may be a little less numerically stable, but that is a difference. In a Quick and dirty test, it shaved about 16% off.

bfm:tmp steve$ cc -O3 m.c m2.c -o m2
bfm:tmp steve$ cc -O3 m.c m1.c -o m1
bfm:tmp steve$ time ./m1
inf

real    0m4.136s
user    0m4.100s
sys 0m0.026s
bfm:tmp steve$ time ./m2
inf

real    0m3.501s
user    0m3.475s
sys 0m0.023s