3 ms·

Ok thanks for answering. In the meantime I had already tested <format> on MSVC as well as godbolt: https://news.ycombinator.com/item?id=36715949 https://news.yc

Ok thanks for answering. In the meantime I had already tested <format> on MSVC as well as godbolt: https://news.ycombinator.com/item?id=36715949 https://news.ycombinator.com/item?id=36715949 Not practical for me to add a second of compile time for each file that wants to print something. > Debian and up to date compilers - pick one. gcc 12.3 was released only a few months ago and is included. gcc 13.1, some 80 days old, doesn't seem to have made it. Not everybody is closely tracking upstream. Immediately jumping on each new train is not my thing (hence why Debian is fine), nor is it how software development is handled in the industry generally. Even on godbolt / gcc 13.1 which I linked in the other post, <format> isn't available. Only {fmt} is available as an optional library. > {fmrt}/<format> are nicer to use than I think otherwise, but maybe you enjoy brewing coffee on top of your desktop computer while waiting for the build to finish. > _faster_ because they are actually dispatched at compile time I don't actually want this unless I'm bottlenecked by the format string parsing. If I have one or two integer formats in my formatting string, the whole thing will already be bottlenecked by that. So "dispatching at compile time" is typically akin to minimizing the size of a truck, when we should have designed a sports car. The thing about format strings and varags is they're in fact an efficient encoding of what you want to do. Not worth emitting code for 2-5 function calls if a single one is enough. If there is a speed problem, you need some wider optimization that the compiler can't help you with. Apart from that, that compile time dispatching doesn't actually happen with fmtlib in the godbolt, not even at -O2. The format string is copied verbatim into the source. Which I like. > If you look at benchmarks on fmt's Github page, you will see it consistently outperforms most other solutions out there, while being completely type safe and extensible. It's IMHO the best of both worlds. Since I've already done a lot of work, show me some realistic and useful benchmark to support your claims?

jstimpfle 3y ago
>> If you look at benchmarks on fmt's Github page, you will see it consistently outperforms most other solutions out there, while being completely type safe and extensible. It's IMHO the best of both worlds. > Since I've already done a lot of work, show me some realistic and useful benchmark to support your claims? Duh, I apologize for not even reading your statement completely. So I went on this page and it is exactly how I imagined. libc printf 0.91s, libfmt 0.74s. 20% speedup is not nothing, but won't help when there is an actual bottleneck. (In this case the general approach has to be changed). Also compiled size is measurably larger even only with a few print statements in the binary. Compile time is f***** 8 times slower! These are all numbers coming from their own page -- expect to have slightly different numbers for your own use cases.

jstimpfle 3y ago

>> If you look at benchmarks on fmt's Github page, you will see it consistently outperforms most other solutions out there, while being completely type safe and extensible. It's IMHO the best of both worlds. > Since I've already done a lot of work, show me some realistic and useful benchmark to support your claims? Duh, I apologize for not even reading your statement completely. So I went on this page and it is exactly how I imagined. libc printf 0.91s, libfmt 0.74s. 20% speedup is not nothing, but won't help when there is an actual bottleneck. (In this case the general approach has to be changed). Also compiled size is measurably larger even only with a few print statements in the binary. Compile time is f***** 8 times slower! These are all numbers coming from their own page -- expect to have slightly different numbers for your own use cases.