You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
take 64-bit double but work with 32-bit float (because float can be losslessly widened to double; note that this is untrue for string-to-floating conversions, where rounding a string to a double and rounding again to a float is a subtle mistake).
Would dedicated 32-bit implementations be even faster, possibly by using narrower multiplications? Like how
Data point: charconv's shortest fixed notation overload benefits from calling d2fixed_buffered_n() for large exactly-representable integer doubles, but not for floats. On x86, the long division technique on uint32_t[4] is significantly faster (71.4 ns versus 101.1 ns, end-to-end cost averaged over all inputs). On x64, long division is very slightly faster (51.4 ns versus 52.1 ns). As a result I'll continue using long division for float, unless/until f2fixed() is implemented.
ryu/ryu/d2fixed.c
Line 395 in a73883c
ryu/ryu/d2fixed.c
Line 597 in a73883c
double
but work with 32-bitfloat
(becausefloat
can be losslessly widened todouble
; note that this is untrue for string-to-floating conversions, where rounding a string to adouble
and rounding again to afloat
is a subtle mistake).Would dedicated 32-bit implementations be even faster, possibly by using narrower multiplications? Like how
ryu/ryu/f2s.c
Line 154 in a73883c
ryu/ryu/d2s.c
Line 238 in a73883c
The text was updated successfully, but these errors were encountered: