Using fast_float library for faster parsing of 64 decimal strings.#11884
Conversation
|
Upgrading to 3.10.1 might be better: https://github.com/fastfloat/fast_float/releases/tag/v3.10.1 |
There was a problem hiding this comment.
If you want to catch potential errors, you ought to add..
if(answer.ec != std::errc()) { /* do something */ }(Note that the library follows the C++ standard so that's how we handle errors. We did not design this approach.)
There was a problem hiding this comment.
@lemire I've added a error reporting via errno same like strtod.
|
This looks simple enough. My main concern is that you do not check for the error field after parsing. If you only rarely invoke strtod, then switching to the canonical fast_float API might be simpler. Whether this matters for your application, I do not know. Note that fast_float relies on the C++17 standard API, so adopting the fast_float API is not akin to vendor lockin... it is a standard!!! |
|
Note that the fast_float library has been adopted by webkit (Apple Safari) and other important systems such as GCC. |
|
The library is now part of Chromium (Chrome etc.). |
Thank you @lemire! I've updated to v6.1.4 using: will check the results on 2 tests in which we retrive 100 and 1000 elements with float scores and update this PR with results |
Automated performance analysis summaryThis comment was automatically generated given there is performance data available. Using platform named: intel64-ubuntu22.04-redis-icx1 to do the comparison. In summary:
You can check a comparison in detail via the grafana link Comparison between unstable and fast_float.Time Period from 5 months ago. (environment used: oss-standalone) Improvements Table
Improvements test regexp names: memtier_benchmark-1Mkeys-load-zset-with-10-elements-double-score|memtier_benchmark-1key-zset-100-elements-zrange-all-elements Full Results table:
|
|
https://github.com/sundb/redis/actions/runs/10450491468 |
@sundb I believe they will all be related to g++ usage. Need to confirm with you guys that g++ dependency is something we're ok with. In the meantime will fix the failures :) thank you! |
fcd5155 to
ea4a9a8
Compare
@sundb can you trigger it again. I believe it's all fixed now |
|
@fcostaoliveira it failed on 32bit and freebsd: https://github.com/sundb/redis/actions/runs/10463748594 |
… default compilers on freebsd test
@sundb now fixed :) |
…he CFLAGS via the main project
… GEOADD, GEORADIUS/GEOSEARCH, ZADD, and some ZUNION use-cases
…st (empty string passed) within getDoubleFromObject()
| value = fast_float_strtod(o->ptr, &eptr); | ||
| /* check end pointer is not the null terminator, that the value a number, | ||
| and that the pointer to the last char is not equal to the first (empty string passed) */ | ||
| if (eptr[0] != '\0' || isnan(value) || (eptr[0] == ((char *)o->ptr)[0])) return C_ERR; |
There was a problem hiding this comment.
why not keep the old string2d() which also uses fast_float_strtod()?
|
@sundb after rebasing from unstable and also doing the latest PR requests confirmed all improvements stay the same, with improvements reaching 26% on the achievable ops/sec (without pipelining) : To replicate: Results:
|
CE Performance Automation : step 2 of 2 (benchmark) FINISHED.This comment was automatically generated given a benchmark was triggered. Started benchmark suite at 2024-10-20 07:59:24.154571 and took 1.256626 seconds to finish. In total will run 1 benchmarks. |
#13845) Since #11884, what was previously accepted as a valid input (hexadecimal string) before 8.0 returned an error. This PR addresses it. To avoid performance penalties if hints the compiler that the fallbacks are not likely to happen. Furthermore, we were ignoring std::result_out_of_range outputs from fast_float. This PR addresses it as well and includes tests for both identified scenarios. --------- Co-authored-by: debing.sun <debing.sun@redis.com>
Fixes #8825
We're using the fast_float library1 in our (compiled-in) floating-point fast_float_strtod implementation for faster and more portable parsing of 64 decimal strings.
The single file fast_float.h is an amalgamation of the entire library, which can be (re)generated with the amalgamate.py script (from the fast_float repository) via the command:
The used commit from fast_float library was the one from https://github.com/fastfloat/fast_float/releases/tag/v3.10.1
Still TODO: