Am 28.04.2018 um 10:11 schrieb Thorsten Engler:
Oops, small mistake caused by last minute change (I replaced rol with
shl): it needs to be shr (or ror or rol, they all perform about the
same on my cpu).
And in case anyone wonders, the first cmp and branch returns 0 for
numbers that would cause an integer overflow, and the 2^nd cmp and
branch skips the whole thing if the input is between -1 and 1 (so it
already is just a fraction).
Also, at least on my CPU (AMD Phenom II X6, so not exactly the newest)
the effect of code alignment on performance is huge. (It affects the
branch predictor I think.) I’m not sure what the best alignment is for
all CPUs.
.align 16 forces alignment of the function entry point to a multiple
of 16. If I add between 0 and 3 nops at the start of the function, the
timings for calling it 10 million times are:
The question is whether we should really return 0 for numbers that would
cause an integer overflow as from the user's perspective of this
function integers aren't involved at all (after all one passes in a
floating point value and receives one).
Maybe it would be better if we'd provide an optimized Int() function and
Frac() then simply stays "d - Int(d)".
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
