Simple speed up of Lesson 1

[theIDinside]

First off, amazing content. But changing the line drawing function, so that it does not check if it is steep, within the for loop, almost speeds it up by 2x, with -O3 on. So, with sacrificing for a little extra code bloat, if one changes the for loop, from

    for (int x=x0; x<=x1; x++) { 
        if (steep) { 
            image.set(y, x, color); 
        } else { 
            image.set(x, y, color); 
        } 
        error2 += derror2; 
        if (error2 > dx) { 
            y += (y1>y0?1:-1); 
            error2 -= dx*2; 
        } 
    } 

to instead

    if(steep) {
        for(int x = x0; x<=x1; ++x) {
            img.set_pixel_color(y, x, color);
            error2 += derror2;
            if(error2 > dx) {
                y += (y1>y0? 1 : -1);
                error2 -= dx*2;
            }
        }
    } else {
        for(int x = x0; x<=x1; ++x) {
            img.set_pixel_color(x, y, color);
            error2 += derror2;
            if(error2 > dx) {
                y += (y1>y0? 1 : -1);
                error2 -= dx*2;
            }
        }
    }

We suddenly eliminate one of the biggest bad guys in programming, branching, and especially branching inside for loops. This also leaves even more room for the optimizer to optimize better. Granted, some optimizer (perhaps) are smart enough to see this on it's own, but it really isn't good practice to count on that in this case. Using rudimentary system_clock and measuring in microseconds, drawing the wire frame image, goes from around ~44000us to ~22000 us, on my system. So it's a pretty impressive speedup to eliminate the branch instruction inside a loop.

[ssloy]

Thank you, this is a good point!

[mtexier]

Hi,

You can also do the same for:
(y1>y0? 1 : -1);
By computing increment value at the start of the function:
const int yincr = (y1>y0? 1 : -1);
and then only doing a
y += yincr;
in the loop.

[theIDinside]

I closed the issue, after trying both gcc and clang-8 as compilers, and the current standards for those, are that they (at any optimization level) will do what (supposedly is called) loop unhoisting, and compilers are smart enough today, to figure out that, if the variable is not a global one (therefore thread safe), it will move it out of the for loop. But it's always a good thing to consider I suppose.