[libcxx-commits] [PATCH] D70631: Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Wed Dec 11 23:57:56 PST 2019

expnkx added a comment.

In D70631#1767987 <https://reviews.llvm.org/D70631#1767987>, @jorgbrown wrote:

> In D70631#1761886 <https://reviews.llvm.org/D70631#1761886>, @expnkx wrote:
>
> > assuming long double is 64 bits is stupid.
>
>
> I agree, actually.  We'll fix this shortly afterward.
>
> > Also why I do not use VC. 64 bits long double and no any kind of assembly allowed is a joke. 
> >  They could not prove the algorithm is right as well since Ryu only provides a small part of algorithm.
>
> Can you prove the algorithm wrong?  I was on the way to my own charconv implementation, and forced to give it up because the implementation in VC was both faster and more correct.  (Specifically, there were rare cases where VC was producing one less digit.)
>
> > charconv is a mistake. It does not worth the effort for implementing this. It does not make your code faster since most problems are iostreams and stdio.h's problem.
>
> But both iostream and stdio.h are much, much slower than this code.  A factor of 10 or more.
>
> > There are NO algorithms on the world to make it correct including Ryu (Ryu is not panacea although STL keeps spreading false information).
>
> You sound very convinced of this, so I'm hoping you have some examples where this implementation produces incorrect results?  Certainly, we could use the test cases.

The problem is that you won't just avoid iostream/stdio.h for your outputting. Even speed up 10x on parsing strings/double make no sense in real world because you still have to use stdio and iostream for doing the IO part which basically eliminates all the gain from charconv.

You cannot avoid clocale. You cannot avoid iostates. You cannot avoid virtual function calls. You cannot avoid all the bad stuff iostream and stdio.h provide.

I would like to just remove iostream and stdio.h in the future instead of just fixing one part. The entire IO libraries in C and C++ need to be removed.

Not mentioning return-to-libc vulnerabilities and accepts this as implementation of CRT would make it even worse.

Here are my benchmarks to show why charconv is a mistake since it reduces your performance from the optimal implementation for at least 4 times.
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/default/

g++ (cqwrteur) 10.0.0 20191031 (experimental)

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

cqwrteur at DESKTOP-7H7UHQ9:~/fast_io/examples/build$ ./output_10M_size_t

std::FILE*:     0.56558740s

std::ofstream:  0.57254780s

std::ofstream with tricks:      0.37952570s

std::to_chars + ofstream rdbuf tricks:  0.16530360s

std::to_chars + obuf:   0.12705310s

obuf:   0.07508470s

Charconv does not save you in any case.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70631/new/

https://reviews.llvm.org/D70631