Fast, locale independent, round trip serialization of numbers is exactly what we needed a long time ago. The additional speed improvements are always welcome. Pity that it doesn't support wchar_t. It might be an option for us to workaround it and add the conversion from string to wstring ourselves.
It would be fairly easy to template the code on character type (crucially, the lookup tables aren't affected; I use a lookup table to convert char to digit which wouldn't be possible for wider types, but that's fine), so I could imagine a proposal being accepted.
Wish I'd had the "plain" to_chars mode a few years ago. I was working on a compiler and the compiler itself would crash when outputting the trace of a specific compiler test. It turns out the sprintf of a long double was overflowing the buffer and stomping the return pointer. Didn't have access to snprintf because of the platform. This is how I discovered general mode, but "plain" was really what I wanted.
Can we please get arbitrary (multiple) precision in the standard library though? GMP may be awesome but there is a real shortage of well supported higher level libraries utilizing multiple precision because adding the implementation is often not very straightforward. I suspect that it would be a lot easier for higher level libraries to add support if these types were available in the standard library and could be easily dropped in.
I guess because log2(10)≈3.32192809489? When you divide by 10 you lose precision and it takes many more cycles. Also, he didn't state that dividing by a power of 10 in one step (e.g. div 10e5) was wrong, but repeatedly doing that (div 10 div 10 div 10 div 10 div 10) to build up the number. PS : Thanks for the CppCheck addin! (I presume you are the same guy/girl?)
I admire this channel's ability to put < and > symbols in the title even when youtube disallows it
This guys always gives some of the best talks in CppCon
Thanks! :-)
Would be nice if this library provided you with constants for the right size of the buffer to accomodate the worst case for each numeric type.
Wow! Steven is a great speaker!
Awesome talk. I did learn quite a bit of new things :-)
Great talk, as always. Ryu seems to be a real game changer.
Packed content, concise explanation, great talk!
Fast, locale independent, round trip serialization of numbers is exactly what we needed a long time ago. The additional speed improvements are always welcome. Pity that it doesn't support wchar_t. It might be an option for us to workaround it and add the conversion from string to wstring ourselves.
It would be fairly easy to template the code on character type (crucially, the lookup tables aren't affected; I use a lookup table to convert char to digit which wouldn't be possible for wider types, but that's fine), so I could imagine a proposal being accepted.
besides using a (weird/legacy) library or using the Windows API, why do you use wchar_t?
Great talk. Going to watch Ryu stuff now. As of vectorizing for 32-bit, don't bother. Using 64-bit you can assume SSE2 and use it always.
Wish I'd had the "plain" to_chars mode a few years ago. I was working on a compiler and the compiler itself would crash when outputting the trace of a specific compiler test. It turns out the sprintf of a long double was overflowing the buffer and stomping the return pointer. Didn't have access to snprintf because of the platform. This is how I discovered general mode, but "plain" was really what I wanted.
Charconv has warnings within it according to VC++, which is funny but also makes it impossible to interpret warnings as errors.
Can we please get arbitrary (multiple) precision in the standard library though? GMP may be awesome but there is a real shortage of well supported higher level libraries utilizing multiple precision because adding the implementation is often not very straightforward. I suspect that it would be a lot easier for higher level libraries to add support if these types were available in the standard library and could be easily dropped in.
lol. Ryu is Japanese for dragon. Gotta love programmer humor.
Original algorithm: Dragon4 (1990)
New algorithm: Ryu (2018)
35:40
Link to Ulf''s 2018 PDTI talk: th-cam.com/video/kw-U6smcLzk/w-d-xo.html
How does gcc implement it and how does it perform for RISC-V processors? This would be crucial to know for embedded use.
Great! And Ryu means Dragon in Japanese... Full circle now.
So what exactly is wrong with multiplying and dividing by a power of 10? I often use this to trim the value to N digits after the decimal point.
I guess because log2(10)≈3.32192809489? When you divide by 10 you lose precision and it takes many more cycles. Also, he didn't state that dividing by a power of 10 in one step (e.g. div 10e5) was wrong, but repeatedly doing that (div 10 div 10 div 10 div 10 div 10) to build up the number.
PS : Thanks for the CppCheck addin! (I presume you are the same guy/girl?)
Great talk.
Any links to Ulf talk?
I guess this one th-cam.com/video/kw-U6smcLzk/w-d-xo.html
Check the links slide @51:00
Yikes, that's a lot of memory required for this then. RIP embedded use :(
I thought the same. Well i'll test it anyway, i hope theres a lot of constexpr paths that can be compiled out..