On 09/08/2016 09:39 AM, Михаил Бахтерев wrote:
> 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.
BTW, I would be OK with the bit-twiddling hack, if we had an autoconf
check for IEEE 754 floats, and a graceful fallback for other systems.
The fallback could be simply the current penalty function. You wouldn't
get the benefit from the better penalty function on non-IEEE systems,
then, but it would still be correct.
> 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.
The compiler should be smart enough to generate the same instructions
either way. A union might be more readable, though. (We don't need to
extract the mantissa, exponent and sign, so a union of float and int32
would do.)
- Heikki
