fast reciprocal (1/x) I was seeing alot of machine learning applications calculate fitness via 1.0 / x. Division in computers is slow so I came up with a version that is about ~36% fast on my architecture (-march=x86-64).
#include &lt;cmath&gt;    //std::exp2, std::log
#include &lt;numbers&gt;  //std::numbers::log2e
#include &lt;stdlib.h&gt; //rand, srand
#include &lt;iostream&gt; //std::cout

float reciprical( float y )
{
    //e^-ln(y)
    //std::pow( log10e,  -std::log(y) )                   //~19s
    return std::exp2(std::numbers::log2e * -std::log(y)); //~17s
}

float reciprical2( float y )
{
    return 1/y;                                           //~23s
}

int main(){
    srand(1);
    for(int i=0; i &lt; 10000000000; ++i) std::cout &lt;&lt; reciprical(rand());
}

I got inspiration from https://codegolf.stackexchange.com/a/114588
Including IO in a benchmark is no good. I tried some different benchmarks on quick-bench and the results were different: the versions with Expensive Functions (log, exp, etc) were much slower. Looking at the assembly, there was no &quot;cheating&quot; such as vectorizing the benchmark loop with the plain division - on the other hand, maybe that wouldn't be cheating, but a realistic representation of how it may work out in real situations. So you could even say that the division is likely to be better than this result shows in many (but not all) situations.
Such results do depend on the specific micro-architecture though. As a specific example, divss on Intel Haswell and before had less than half the throughput than on Intel Broadwell and later. log and exp can be implemented without division, so the relative cost will be different on different processors. That may also explain part of the differences we observed, but that does not take away that benchmarks should not include significant sources of overhead that aren't the subject of the benchmark.
On your architecture (and many others) there is a special hardware-accelerated approximate reciprocal. Indeed on some architectures, division is not a primitive at all and can only be implemented in terms of such an approximate reciprocal (that's tricky). For x86, you can write this, for a quite accurate but not perfect reciprocal:
float reciprocal(float y)
{
    float r = _mm_cvtss_f32(_mm_rcp_ss(_mm_set_ss(y)));
    r = r * (2 - r * y);
    return r;
}

The Newton-Raphson step is optional if you can accept a reduced precision, with a relative error of up to \$1.5 \cdot 2^{-12}\$.
Note than all the benchmarks that I linked before are for throughput, if you're in a situation where latency is important, an approximate reciprocal followed by a Newton-Raphson step is not actually good. Pentium4 may have been an exception to that, since it had a much slower division, but Pentium4 is not very relevant today.