Excuse me for intervention.
It depends. For instance, i run PostgreSQL on the modern MIPS CPU, which
does not have sqrt support.
But you are right, it is supported in most cases. And if execution speed
of this very fuction is of concern, sqrtf(x) should be used instead of
sqrt(x).
Despite this, Andrew's solution gives more accurate representation of
values. And as far as i understand, this improves overall performance by
decreasing the overall amount of instructions, which must be executed.
It is possible to speed up Andrew's implementation and get rid of
warnings by using bit-masks and unions. Something like:
union { float f; struct { unsigned int mantissa:23, exponent:8, sign:1; } bits; }
I am sorry, i have no time to check this. But it is common wisdom to
avoid pointer-based memory accesses in high-performance code, as they
create a lot of false write-to-read dependencies.
- Mikhail, respectfully
On Wed, Sep 07, 2016 at 05:58:42PM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > Unfortunately, sqrt(x) isn't very cheap.
>
> You'd be surprised: sqrt is built-in on most modern hardware. On my
> three-year-old workstation, sqrt(x) seems to take about 2.6ns. For
> comparison, the pack_float version posted in
> <CAJEAwVGdb92E-XKfMLN3cxM2BWbbA3rrffzDzg8Ki1H5iQEk2Q@mail.gmail.com>
> takes 3.9ns (and draws multiple compiler warnings, too).
>
> regards, tom lane