When FASTFLOAT_ROUNDS_TO_NEAREST is defined, fast_float assumes that the
rounding mode is the default (round to nearest) and skips the volatile
probe before Clinger's fast path. The FLT_EVAL_METHOD check is kept.
The README documents the tradeoff.
The javascript early-exit checks added in b2e41e8 use fastfloat_unlikely
without the point-of-use clang diagnostic guard that the other call sites
have (see #387), so clang with -pedantic in C++11/14/17 mode warns
"use of the 'unlikely' attribute is a C++20 extension".
Wrap both sites with the same guarded pragma push/pop already used in
parse_number.h and decimal_to_binary.h. No change to code generation.
Add a CI step compiling fast_float.h with clang-14 and
-pedantic-errors -Werror in C++11/14/17/20 to catch regressions.
The fixed-width wrappers parsed into a zero-initialized temporary and
copied it back unconditionally, so invalid input overwrote the
destination with zero. Copy back only when the result is not
invalid_argument, as required by [charconv.from.chars]/1.
Negating the most negative int64_t is undefined behaviour. GCC at -O2 uses that to turn the fast-path mantissa bound into a signed compare and returns the wrong sign, so take the magnitude in uint64_t instead.
Clang generated ~35% more instructions per float than GCC on identical
code (canada.txt, 64-bit: 276 vs 200 i/f on a Xeon Gold 6548N). Two
causes, confirmed with exact instruction traces:
1. Clang declines to inline the parser (from_chars_caller<T>::call) into
its callers, so parse_options stays a runtime value and every format
flag is re-tested on every conversion: javascript, skip_white_space,
allow_leading_plus, fixed/scientific, the decimal point, the JSON
dispatch. GCC inlines the whole parser into each call site, where
chars_format::general is a constant, and all of it folds away.
Fix: from_chars dispatches chars_format::general to a
from_chars_fixed_format<T, UC, Fmt> instantiation, so the format is a
compile-time constant inside the parser body whether or not the user's
call is inlined. The call forwarder gets fastfloat_clang_really_inline
so that it folds into that instantiation.
2. Clang if-converts the rare over/underflow fix-ups at the end of
compute_float and the result_out_of_range test into cmov chains that
every conversion executes. Marking them fastfloat_clang_unlikely keeps
them as never-taken branches.
Both are applied under clang only, and GCC's generated code is identical
to before (verified on the object code). That is on purpose: forcing
always_inline on from_chars, or even on the trivial call forwarder,
regressed GCC by up to 14% on mesh.txt by changing its inlining order;
dispatching to the fixed-format instantiation made it stop inlining into
the loop; and the unlikely hints alone cost it 2-6% on mesh.txt by
reordering blocks (GCC already emits branches there).
realbenchmark, cycles per float, 5 interleaved rounds, medians:
clang 21, Xeon Gold 6548N before after
canada.txt ASCII (64) 49.7 44.6 -10%
canada.txt UTF-16 (64) 57.4 52.0 -9%
mesh.txt ASCII (64) 26.5 22.4 -16%
mesh.txt UTF-16 (64) 28.1 24.0 -15%
(32-bit: -8% to -14%)
gcc 14, same machine: generated code unchanged.
Apple clang 17, arm64: +3% to +18% Mfloat/s.
PR #356 replaced the 3/5-character case-insensitive compare used by
parse_infnan with SWAR helpers (fastfloat_strncasecmp3/5 plus a generic
memcpy-based fastfloat_strncasecmp). That code only runs for "nan",
"inf" and "infinity" inputs, so it cannot help ordinary parsing, but it
grew the inlined inf/nan tail of the parser: on x86-64 (GCC 14 and
clang 21) the per-commit benchmarks dropped by 1.5-2.5% because the
extra dead code changed inlining decisions and register allocation on
the hot path (+7 instructions/float on canada.txt).
Go back to the plain loop, which the compiler unrolls for the constant
lengths 3 and 5, and drop the now-unused generic SWAR function. The
`actual < 256` guard of the original is unnecessary: OR-ing 0x20 into
a value can only equal an ASCII lowercase letter when the value is that
letter or its uppercase form, so the plain OR is exact for every
character type.
8.3.0 added the ECMAScript leading-zero rule as a runtime test on fmt inside
parse_number_string, so unlike basic_json_fmt its error returns and Annex B
octal scan land in the parser body that every from_chars instantiation
force-inlines. from_chars_caller<double>::call grew from 935 to 1031
instructions and other formats lost about 3% on short inputs.
Make the rule a compile-time parameter of the parser body, selected once at the
entry point, and take chars_format::javascript out to a cold conversion before
anything else is live so the branch is a tail call. parse_number_string keeps
its signature and behaviour.
benchmarks/benchmark.cpp, Intel Xeon 6975P-C, clang 22.1.8, cycles per float,
best of 7:
canada.txt mesh.txt
8.2.10 47.03 24.78
8.3.0 47.34 26.08
this 46.28 24.86
This fixes a compile error in all clang versions lower than 10,
triggered by the use of the pragma ignore with what is an unknown
warning on those compiler versions:
```
/__w/ext/fast_float/include/fast_float/parse_number.h:361:34: error: unknown warning group '-Wc++20-extensions', ignored [-Werror,-Wunknown-pragmas]
```
The fix requires looking at __clang_major__, which is unfortunately
different in Apple, so a version dispatch is required.
parsed_number_string_t carries two span<UC const> members (integer, fraction)
that are only read on the rare slow paths (digit_comp, and the >19-significant-
digit truncation recompute). Materializing them on every parse forces the ~56/64-
byte struct to be written out and marshaled through the by-value return, which
shows up as backend/store pressure on the hot path.
This adds a runtime `store_spans` flag (default true, so all existing callers are
unchanged) to parse_number_string; from_chars_float_advanced parses with it false,
attempts the Clinger and Eisel-Lemire fast paths inline, and only re-parses with
spans on the two rare slow branches. The re-parse is pushed into a single
`fastfloat_noinline` (noinline+cold) helper so the force-inlined hot scanner is
emitted once rather than duplicated into the caller (without this the extra inline
copies regress some targets, e.g. ARM gcc, by bloating the hot frame and lengthening
the loop-carried dependency chain).
A runtime flag is used deliberately rather than a template parameter: a template
would create a second instantiation of the whole scanner whose icache cost wipes
out the gain.
Measured (per-parser microbench, median of 5, pinned core), fast_float from_chars
<double>/<float>, vs the current tip:
- Intel Ice Lake (Xeon 8360Y): +17-19% (gcc), Intel TMA shows backend-bound
26.0% -> 2.2% and retiring 60.3% -> 77.3% on short floats (the eliminated span
spill), with -36% pipeline slots.
- Intel Cascade Lake (Xeon 6248): +18-22% (gcc), +13-23% (clang).
- ARM Neoverse-V2 (Graviton4): +73-196% (gcc), +8-11% (clang) -- the struct spill
dominated the gcc hot loop there.
Correctness: the full float exhaustive suite (exhaustive32, exhaustive32_64,
exhaustive32_midpoint, random64) passes, and a 2^32 sweep is byte-identical to the
current tip. Public from_chars / from_chars_advanced / parsed_number_string_t are
unchanged.
manually checked modified files for errors, but not committing .clang-format due to the following warning:
>>> Setting `QualifierAlignment` to something other than `Leave`, COULD lead to incorrect code formatting due to incorrect decisions made due to clang-formats lack of complete semantic information. As such extra care should be taken to review code changes made by the use of this option.
