Awesome
dtoa Benchmark
This is a fork of Milo Yip's dtoa benchmark with CMake support and fixed reporting.
Copyright(c) 2014 Milo Yip (miloyip@gmail.com)
Introduction
This benchmark evaluates the performance of conversion from double precision IEEE-754 floating point (double
) to ASCII string. The function prototype is:
void dtoa(double value, char* buffer);
The character string result must be convertible to the original value exactly via some correct implementation of strtod()
, i.e. roundtrip convertible.
Note that dtoa()
is not a standard function in C and C++.
Procedure
Firstly the program verifies the correctness of implementations.
Then, one case for benchmark is carried out:
- RandomDigit: Generates 1000 random
double
values, filtered out+/-inf
andnan
. Then convert them to limited precision (1 to 17 decimal digits in significand). Finally convert these numbers into ASCII.
Each digit group is run for 100 times. The minimum time duration is measured for 10 trials.
Build and Run
- Configure:
cmake .
- Build:
make
- Run benchmark:
./dtoa-benchmark
- On success, run the
dtoa
executable is generated atdtoa-benchmark/
- The results in CSV format will be written to
dtoa-benchmark/result
. - Run GNU
make
indtoa-benchmark/result
to generate results in HTML.
Results
The following are results measured on a MacBook Pro (2.8 GHz Quad-Core Intel Core i7), where dtoa()
is compiled by clang 12.0.0 (clang-1200.0.32.2) and run on macOS. The speedup is based on sprintf()
.
Function | Time (ns) | Speedup |
---|---|---|
ostringstream | 1,187.735 | 0.75x |
ostrstream | 1,048.512 | 0.85x |
sprint | 887.735 | 1.00x |
fpconv | 119.024 | 7.46x |
grisu2 | 101.082 | 8.78x |
doubleconv | 84.359 | 10.52x |
milo | 64.100 | 13.85x |
ryu | 43.541 | 20.39x |
fmt | 40.712 | 21.81x |
null | 1.200 | 739.78x |
Note that the null
implementation does nothing. It measures the overheads of looping and function call.
Some results of various configurations are located at dtoa-benchmark/result
. They can be accessed online, with interactivity provided by Google Charts:
- corei7920@2.67_win32_vc2013
- corei7920@2.67_win64_vc2013
- corei7920@2.67_cygwin32_gcc4.8
- corei7920@2.67_cygwin64_gcc4.8
Implementations
Function | Description |
---|---|
ostringstream | std::ostringstream in C++ standard library with setprecision(17) . |
ostrstream | std::ostrstream in C++ standard library with setprecision(17) . |
sprintf | sprintf() in C standard library with "%.17g" format. |
gay | David M. Gay's dtoa() C implementation. |
grisu2 | Florian Loitsch's Grisu2 C implementation [1]. |
doubleconv | C++ implementation extracted from Google's V8 JavaScript Engine with EcmaScriptConverter().ToShortest() (based on Grisu3, fall back to slower bignum algorithm when Grisu3 failed to produce shortest implementation). |
fpconv | night-shift's Grisu2 C implementation. |
milo | miloyip's Grisu2 C++ header-only implementation. |
fmt | fmt::format_to with format string compilation. |
null | Do nothing. |
Notes:
-
tostring()
is not tested as it does not fulfill the roundtrip requirement. -
Grisu2 is chosen because it can generate better human-readable number and >99.9% of results are in shortest. Grisu3 needs another
dtoa()
implementation for not meeting the shortest requirement.
FAQ
-
How to add an implementation?
You may clone an existing implementation file. And then modify it and add to the CMake config. Note that it will automatically register to the benchmark by macro
REGISTER_TEST(name)
.Making pull request of new implementations is welcome.
-
Why not converting
double
tostd::string
?It may introduce heap allocation, which is a big overhead. User can easily wrap these low-level functions to return
std::string
, if needed. -
Why fast
dtoa()
functions is needed?They are a very common operations in writing data in text format. The standard way of
sprintf()
,std::stringstream
, often provides poor performance. The author of this benchmark would optimize thesprintf
implementation in RapidJSON, thus he creates this project.
References
[1] Loitsch, Florian. "Printing floating-point numbers quickly and accurately with integers." ACM Sigplan Notices 45.6 (2010): 233-243.