4 ms·

The author has made a rebuttal to this comment: https://github.com/expnkx/fast_io/commit/8cf7497593eb185bba13ad0154a6dfab5a534388 https://github.com/expnkx/fast

The author has made a rebuttal to this comment: https://github.com/expnkx/fast_io/commit/8cf7497593eb185bba13ad0154a6dfab5a534388 https://github.com/expnkx/fast_io/commit/8cf7497593eb185bba1...

usefulcat 6y ago
I wonder why not provide source for benchmarks?
- expnkx 6y ago
  Source is here: https://github.com/expnkx/fast_io/tree/master/benchmarks/0015.fast_io_vs_fmt/benchmark https://github.com/expnkx/fast_io/tree/master/benchmarks/001... Including video: https://www.youtube.com/watch?v=avyIFLuFUQs https://www.youtube.com/watch?v=avyIFLuFUQs
vitaut 6y ago
The new benchmark is even less meaningful because 1. It now constructs unnecessary `std::string` penalizing `format_int`: value+=fmt::format_int(i).str().size(); 2. The input is consecutive numbers which makes branches well predicted which is not realistic but beneficial for fast_io integer formatter which has a lot of branches. The precomputed table you can find in include/fast_io_core_impl/integers/jiaendu/table_gen.h
- usefulcat 6y ago
  > 1. It now constructs unnecessary `std::string` penalizing `format_int`: > value+=fmt::format_int(i).str().size(); Author appears to be doing the equivalent in the other benchmark: value+=fast_io::to<std::string>(i).size(); Maybe you could argue that in both cases it would be better not to measure time spent creating and destroying strings, but I don't see how the two benchmarks are not comparable.
  - vitaut 6y ago
    If std::string construction was the goal then sure, but that's not what the original benchmark that I've written was about. The goal was to find the fastest way to format an integer with or without std::string construction: http://www.zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html http://www.zverovich.net/2013/09/07/integer-to-string-conver.... Those methods that construct a string but not required to are explicitly marked. The OP made some claims based on the method that doesn't construct std::string (which is one of the reasons it's rather fast) and then when I pointed out that it's unsafe switched to a much slower one but at the same time unnecessarily penalized other methods. It seems like moving a goalpost just to prove that your method is the fastest (which might be true but we don't know because of a poor methodology).

The author has made a rebuttal to this comment: https://github.com/expnkx/fast_io/commit/8cf7497593eb185bba13ad0154a6dfab5a534388 https://github.com/expnkx/fast_io/commit/8cf7497593eb185bba1...

usefulcat 6y ago

I wonder why not provide source for benchmarks?

expnkx 6y ago
Source is here: https://github.com/expnkx/fast_io/tree/master/benchmarks/0015.fast_io_vs_fmt/benchmark https://github.com/expnkx/fast_io/tree/master/benchmarks/001... Including video: https://www.youtube.com/watch?v=avyIFLuFUQs https://www.youtube.com/watch?v=avyIFLuFUQs

vitaut 6y ago

The new benchmark is even less meaningful because 1. It now constructs unnecessary `std::string` penalizing `format_int`: value+=fmt::format_int(i).str().size(); 2. The input is consecutive numbers which makes branches well predicted which is not realistic but beneficial for fast_io integer formatter which has a lot of branches. The precomputed table you can find in include/fast_io_core_impl/integers/jiaendu/table_gen.h

usefulcat 6y ago
> 1. It now constructs unnecessary `std::string` penalizing `format_int`: > value+=fmt::format_int(i).str().size(); Author appears to be doing the equivalent in the other benchmark: value+=fast_io::to<std::string>(i).size(); Maybe you could argue that in both cases it would be better not to measure time spent creating and destroying strings, but I don't see how the two benchmarks are not comparable.
- vitaut 6y ago
  If std::string construction was the goal then sure, but that's not what the original benchmark that I've written was about. The goal was to find the fastest way to format an integer with or without std::string construction: http://www.zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html http://www.zverovich.net/2013/09/07/integer-to-string-conver.... Those methods that construct a string but not required to are explicitly marked. The OP made some claims based on the method that doesn't construct std::string (which is one of the reasons it's rather fast) and then when I pointed out that it's unsafe switched to a much slower one but at the same time unnecessarily penalized other methods. It seems like moving a goalpost just to prove that your method is the fastest (which might be true but we don't know because of a poor methodology).