[clarry]

This one shows the branchy and branchless variations of bresenham being nearly equal in speed, within 5% on the older 32 bit CPU, with the branchy old school way being 1% faster on a more recent 64 bit CPU.

Both are significantly faster than the naive floating point version.

That is in line with my experience that floating point can still be quite slow on the CPU; the advantage from using fixed point isn't necessarily in avoiding branches (though it usually helps), but in avoiding floating point computation and conversion between floats & ints. Which is something something you have to deal with as soon as you're addressing memory or trying to pack data e.g. in video coding.

[pandaman]

Did you forget to add a link to your post or something? I repeat this for the final time: floating point can be quite slow but flow control is much slower. Also, fixed point square root is very slow compared to the FP one.

If you have a "brancheless bresenham" then go for it, I've never heard of such a thing so I'd be curious to see that link. But from the description it sounds like a contradiction to the Bresenham's idea.

[clarry]

See userbinator's link for a little performance comparison of the naive floating point code vs. bresenham vs. fixed point.

[pandaman]

There are many problems with that link. First of all - there is no "branchless bresenham" in it. Second - the author, while noticing that float to int conversion in his compiler is slow, decided not to do anything about it instead of doing a simple google search to find how to do it fast enough. Third - he is using 8087 FP instructions, which had been deprecated since late 90s. Fourth - he is essentially measuring function call (look what's happening in his inner loop). And fifth - he is not measuring other Bresenham's algorithms. I'd love to see how he does ellipses with fixed point.