Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: We have a new standard! Date: Tue, 07 Jan 2025 21:15:08 -0800 Organization: A noiseless patient Spider Lines: 64 Message-ID: <86a5c1antv.fsf@linuxsc.com> References: <20250101182527.00004b2f@yahoo.com> <86msg9a9t1.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 08 Jan 2025 06:15:12 +0100 (CET) Injection-Info: dont-email.me; posting-host="6e19b66cb0c542b6b8c649f7413a0cd9"; logging-data="2790757"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+vZGcratb3xdJ6fIspfzvE33mljWyBjq8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:DE45brM+ekjuF4WjHQ+xDxHiaAI= sha1:rgNT8HzLHW5Gnp+Nz8zRncTTYnU= Xref: csiph.com comp.lang.c++:121424 Paavo Helde writes: > On 02.01.2025 10:39, Tim Rentsch wrote: > >> Paavo Helde writes: >> >> [...] >> >>> Half of the slowness of both in C printf() and C++ streams comes >>> from the locale support, [...] >> >> I find this assertion very hard to believe (specifically, for >> printf(); I might guess that C++ streams have similar >> performance characteristics, but I don't have nearly as much >> experience with C++ streams as I do with printf()). >> >> Is there anything else you can say about it besides an >> unsupported assertion? > > Probably you were misled by my vague word usage. I said "half of the > slowness", not "half of the total time". As "slowness" is nowhere > exactly defined, this was just a figure of speech, no need to get > overly upset about that. I'm not upset, just disappointed. I consider you one of the better contributors in the newsgroups, and so it's surprising to see a statement from you with zero information content. > Anyway, I have profiled the writing of large CSV tables (multi-GB) > which was deemed too slow. 90% of time was spent in sprintf() calls, > from which 10% was spent in locale-related routines, presumably for > checking that the global process locale has not changed during the > last microsecond. Considering that our CSV file format had to always > use the fixed C-locale format anyway, this locale checking was > something which was absolutely unneeded. The 10% number is interesting, and disappointing. Surely the authors of the standard library implementation could have done better. Incidentally, I did a measurement of the cost of localeconv() on my test server (running Ubuntu), and that gave a result in line with your 10% number. > We tried to parallelize the writing, expecting to increase the speed N > times by using N threads, but alas, as the locale is a global > thread-shared object, now the threads started to fight over it and the > performance did not scale nowhere near to our expectations. (The > thread-specific locales were not available an all needed platforms). Does the C standard (or the C++ standard) allow locale information to be thread-specific? I don't see anything in the C standard that looks like the functions can be anything but global. I haven't looked at what C++ allows. > We resolved it finally by using std::to_chars() for integer data and > Google's double-conversion library for floating-point data (our C++ > implementations did not support std::to_chars() on floating-point data > on all needed platforms at that time). It's disappointing that the C standard (and I assume also the C++ standard) doesn't provide conversion functions that don't use global locale information. Oh, come to think of it, I think I saw some C++ functions (in which C++ standard I don't know) that pass locale information in explicitly, which is probably what you were alluding to above.