Mastodawn

Oliver Schönrock

yes, I am aware.

I just thought Jason covering it, would be good opportunity to broaden awareness of the real cause of the issue (QoI) and that we can hopefully expect improvements.

stdlibc++ needs to follow suit...
waiting for MSVC might take a long time.

@oschonrock They are all aware. The problems is that WG21 has been dumping tons of garbage and the number of maintainers is very low.

@oschonrock It might be sufficient for one implementation to do it correctly and the others will be shamed into doing the same.

I think there are plenty of non-committee people who are not aware that <format> and <print> compiling at turtle speed and bloating binaries to supernova size is a pure QoI issue...

Even Jason didn't really make that clear in his video. I assume he knows, but most of the audience doesn't, as can be seen by the comments.

@oschonrock They are not really bloating binaries that much, "only" object files. The final binary should still have one copy of all formatting code.

@oschonrock I'm fine with youtube "experts" throwing shit at current standard library implementations of std::print until the latter are improved (and possibly after)

I agree...

However, many of the comments are:

"the committee is crazy, they standardised garbage".

incorrect, but that's the most popular misinterpretation.

@oschonrock I mean, have you seen youtube comments in general?

yes, they are horrific....,

but it would help everyone, if someone like Jason, who is perhaps one of the best known communicators in the community, would say:

"there is no need for these to be slow to compile or to produce binaries which are bloated and you can't effectively inspect in CE. Look at fmtlib... this i is a QoI by the vendors"....

@oschonrock that's more of an ask to @lefticus

@vitaut @lefticus

it is... but I was suggesting that you should ask him...

he is more likely to do it then ;-)

Jason Turner Mar 9

@oschonrock I mean I thought I did imply that it's possible to do it better since {fmt} does do it better.

@lefticus

You did... too subtly IMHO.

Those compilation speeds make <format> and <print> basically unusable, not just on CE, but locally as well.

and this is since c++20.

Jason Turner Mar 9

@oschonrock well if history is any indicator, someone who implements this will probably see it.

But really the implementers are overworked already, IMO.

@lefticus

I am sure that is correct.

It's unfortunate that the perhaps "the most mainstream feature"

ie "how to print hello world"

remains borderline unusable after so many years. Affects a lot of people.

But I guess everyone says that about their pet feature?

@oschonrock @lefticus Note that print is 23. I'm more concerned that std::string is unusable but Jonathan Wakely promised that they'll fix it anytime now.

@vitaut @lefticus

Yeah but <format> is most of the feature.

@oschonrock @lefticus Interestingly you can improve them completely independently.

@vitaut @oschonrock @lefticus

Peter Sommerlad Mar 10

what is the underlying issue with std::string in libstdc++?

@PeterSommerlad @vitaut @oschonrock @lefticus

I _think_ he means that for C++20 we don't enable the explicit instantiation declarations (i.e. 'extern template') for std::string, so everything that uses std::string in C++20 (and later) compiles slower than in C++17 mode. And of course std::format uses std::string.

It's on our TODO list, but I don't want to make changes to the exported symbols until closer to the GCC 16 release. Which is getting very close now.

@oschonrock @lefticus

"basically unusable" ... and that's why I don't take internet people seriously.

Tobias Hunger Mar 10

@oschonrock @vitaut When nobody implements something in a great way, then maybe it is not an implementation issue? Maybe it is the standard? Or maybe it is an organisational issue?

Maybe people that care for C++ need to maintain a good reference compiler frontend and let the compiler people care for the compiler backend stuff?

@hunger @vitaut

It is precisely this lack of clarity why i brought this up.

There is an excellent reference implementation.

It's called {fmt}.

https://godbolt.org/z/aszhcjcPe

@hunger @vitaut

Also. I was wrong about MSVC. It's fast on this feature with no bloat.

So that's 2 implementations which are decent.

Looks like QoI, not the standard.

C'mon Oliver, you can do better and check the facts first:

Compiler Explorer - C++

auto main() -> int { std::print("Hello world!"); }

@DanielaKEngert @vitaut

OK Dani, I stand corrected. 🫡

Bloat is gone. How is the speed?
CE link was cached, and not sure how to turn it off.

So does @vitaut 's theory apply?

Will the other Vendors be shamed into fixing their QoI?

@oschonrock @vitaut
@lefticus

Dani (

Antifascista)Mar 10

Simply change the source a bit, e.g. like so:

https://godbolt.org/z/M944r3z19

Tested right now (twice):
MSVC came back after 1-2 seconds,
Clang after 2-3 seconds,
GCC took forever.

Compiler Explorer - C++

auto main() -> int { std::print("Hello world!"); return 2; }

@DanielaKEngert @vitaut @lefticus

I got similar proportions, but twice as slow for all..

then I tried std::cout <<

clang & MSVC were fastest, about 40% faster than MSVC was on std::print. GCC's std::cout speed was comparable to MSVC's std::print...

But clearly CE is not a repeatable platform for these sorts of tests, nor is this "sample of one" methodology any good.

@DanielaKEngert would you say MSVC std::print speed approaches std::cout?

@oschonrock @vitaut @lefticus

Dani (

Antifascista)Mar 10

Testing speed in CE is more or less futile unless you want to get a first ballpark impression.

Regarding your std::print vs. std::cout question: what is your objective?

- compile throughput?
- runtime performance?
- something else?

In our codebase, not throwing because of stooopid errors is paramount. We switched to fmt::format about a decade ago, and moved on to std::format during the VS2019 time frame - without any regrets due to noticeable build time increases.

@DanielaKEngert @vitaut @lefticus

For me the compile time is the main issue.

But if you switched the whole code base and noticed little difference, that is a decent reference point.

I have tried that on gcc and clang several times and had to revert, the slowdown was too painful.

And that is the point here.
The current compile times on those 2 implementations, of what is an important foundational feature, makes it borderline unusable in practice.

(binary bloat also important for some)

@oschonrock @vitaut @lefticus

Dani (

Antifascista)Mar 10

I totally agree.

With regards to compile time: some may argue that I made it even worse with my compile time checking of the singular *and* plural format strings (i.e. support for internationalization at runtime) plus some additional consistency features. No sweat doing so 😊

@DanielaKEngert @oschonrock Microsoft STL actually implemented it correctly, nice!

@DanielaKEngert @oschonrock Actually Microsoft STL has the same problem so the difference is just a CE artefact: https://github.com/microsoft/STL/blob/26b7ca58ee3151c81736088e554e5797cafca641/stl/inc/format#L3041

STL/stl/inc/format at 26b7ca58ee3151c81736088e554e5797cafca641 · microsoft/STL

MSVC's implementation of the C++ Standard Library. - microsoft/STL

GitHub

@oschonrock @vitaut

Sigh. Firstly, it's libstdc++ not stdlibc++.

Secondly, no, we don't need to. The overhead of <print> is known, and expected. We don't export any C++23 symbols from libstdc++.so yet, so that we can still change things before we are stuck with a stable ABI forever. That means the entire std::print implementation is inline and has to be instantiated and emitted in the TU, instead of just linking to a library function. The choice is to freeze the ABI early and have people complain for eternity, or delay it until we're ready and have people complain about compile times for a year or two.

I suppose what we could do is make it conditionally non-inline, so that if you define a macro like _GLIBCXX_PRINT_EXTERN and link with -lstdc++exp you'd get a non-inline definition. It's not a priority though. As usual, we're focussing on adding features and on correctness, before we try to prematurely optimize.

@wako @oschonrock I'm not sure if it's premature at this point because format has been around for 6 years and has the same QoI problem. As we can see from Jason's video the result is that people are just using old broken APIs.

@vitaut
Yeah for std::format it wouldn't be premature, but GCC 16 will be the first release with complete and stable C++20 support. It's time to optimize it now.

For std::print we're still working on it, and we're not pretending it's optimized or stable yet. Feedback is useful, but entitled demands to fix things tend to have the opposite effect on how I decide on priorities.