vitaut

There are some fundamental reasons why cout is slower than stdio/{fmt}: https://stackoverflow.com/a/65325727/471164.

I agree that modules is the right long-term solution and in fact {fmt} is modularized: https://vitaut.net/posts/2023/cxx20-modules-in-clang/.

Unfortunately the std module alone doesn't help much because 1 second is 3x slower than before the optimization described in the post but maybe more fine-grained modules will (or if std module import made faster).

Good catch, thanks! Fixed now. This explains why the difference was kinda low compared to another benchmark: https://github.com/fmtlib/fmt?tab=readme-ov-file#compile-tim....

Implementations can be improved somewhat but there is a certain set of dependencies that must be included according to the standard and for string it's pretty big.

AFAICS the main problem is that <string> pulls in a lot of dependencies.

std::cout is thread-safe but because of the concatenation-based API parts of the message may interleave. C++23 std::print is safe (and the output doesn't interleave).

See https://vitaut.net/posts/2023/print-in-cpp23/.

This is not about printing hello world but about all formatted I/O which is a significant chunk of the library. To be fair formatted I/O is pretty broken in C as well but for completely different reasons.

It's just one example showing a decent win with minimal efforts. {fmt} is widely used for getting better perf in formatted code.

{fmt} doesn't encourage "custom formatter specification to live in a template". On the contrary, if you look at the docs in https://fmt.dev/latest/api.html#formatting-user-defined-type..., none of the examples is parameterized. One even demonstrates how to define your formatting code in a source file. And if your formatters are so big that they meaningfully impact build speed you are doing something wrong. fmt/core.h is heavily optimized for build speed so you can just use it as a type-safe replacement for *printf. That said, implementations of std::format (especially Microsoft's) may not be as optimized for build speed yet. This will likely improve now that the ABI can be stabilized.

{fmt} is commonly used for performance critical code because it provides some of the fastest numeric formatting and I/O:

* https://vitaut.net/posts/2020/fast-int-to-string-revisited/ * https://github.com/fmtlib/fmt/pull/1882 * https://vitaut.net/posts/2020/optimal-file-buffer-size/

Here's just one example: https://aras-p.info/blog/2022/02/03/Speeding-up-Blender-.obj...

fmt/core.h has been heavily optimized for build speed and is usually faster to compile than equivalent iostream code: https://github.com/fmtlib/fmt?tab=readme-ov-file#compile-tim.... Once modularized std is available we might be able to be compete with printf.

It is weird but not unique to C++. For example, python used the % operator for string formatting. It's a simple but hacky way to feed arbitrary number of arguments in a type-safe way if you don't have variadics.

Did you mean endling?

Glad you asked. I recently wrote a post about it: https://vitaut.net/posts/2023/print-in-cpp23/.

No, thanks.

{fmt} has internal buffering but it's not yet exposed to users. There is a feature request for it: https://github.com/fmtlib/fmt/issues/2354. FILE buffering is not too bad but it can be easily optimized: https://www.zverovich.net/2020/08/04/optimal-file-buffer-siz....

And yet C++ is one of the most popular languages in the world and widely used in the industry including most (all?) tech giants.

It implements nearly all of C++20 std::format: https://fmt.dev/dev/api.html#compatibility-with-c-20-std-for...

If std::string construction was the goal then sure, but that's not what the original benchmark that I've written was about. The goal was to find the fastest way to format an integer with or without std::string construction: http://www.zverovich.net/2013/09/07/integer-to-string-conver.... Those methods that construct a string but not required to are explicitly marked. The OP made some claims based on the method that doesn't construct std::string (which is one of the reasons it's rather fast) and then when I pointed out that it's unsafe switched to a much slower one but at the same time unnecessarily penalized other methods. It seems like moving a goalpost just to prove that your method is the fastest (which might be true but we don't know because of a poor methodology).

The new benchmark is even less meaningful because

1. It now constructs unnecessary `std::string` penalizing `format_int`:

value+=fmt::format_int(i).str().size();

2. The input is consecutive numbers which makes branches well predicted which is not realistic but beneficial for fast_io integer formatter which has a lot of branches.

The precomputed table you can find in include/fast_io_core_impl/integers/jiaendu/table_gen.h

> All i/o libraries eventually hit OS barrier

Indeed.

> I can't really see how it could be optimised to gain 6x speed up.

Performance claims appear to not even be based on I/O but only on two formatting microbenchmarks and are severely misleading https://news.ycombinator.com/item?id=23311726

The formatting part but unfortunately it's just a clickbait: https://news.ycombinator.com/item?id=23311726

Unfortunately performance claims appear to be bogus.

1. ospan, performance claims seem to be based on, doesn't do any bound checks, so you can easily get buffer overflow.

2. fast_io generates a whopping 50kB of static data just to format an integer.

So if these benchmark results are correct (I was not able to verify because the author hasn't provided the benchmark source):

> format_int 7867424 ns 7866027 ns 89 items_per_second=127.129M/s

> fast_io_ospan_res 6871917 ns 6870708 ns 102 items_per_second=145.545M/s

fast_io gives 15% perf improvement by replacing a safe format_int API from https://github.com/fmtlib/fmt with a similar but unsafe one + 50kB of extra data. Adding safety will likely bring perf down which the last line seems to confirm:

> fast_io_concat 7967591 ns 7966162 ns 88 items_per_second=125.531M/s

This shows that fast_io is slightly slower than the equivalent {fmt} code. Again this is from the fast_io's benchmark results that I hasn't been able to reproduce.

50kB may not seem like much but for comparison, after a recent binary size optimization, the whole {fmt} library is around 57kB when compiled with `-Os -flto`: http://www.zverovich.net/2020/05/21/reducing-library-size.ht...

The floating-point benchmark results are even less meaningful. They appear to be based on a benchmark that I wrote to test the worst case Grisu (https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/p...) performance on unrealistic random data with maximum digit count. fast_io compares it to Ryu (https://dl.acm.org/doi/pdf/10.1145/3192366.3192369) where maximum digit count is actually the best case and the performance degrades as the number of digits goes down. A meaningful thing to do would be to use Milo Yip's benchmark instead: https://github.com/miloyip/dtoa-benchmark

In case anyone is interested here's brief history of standardizing std::format: http://www.zverovich.net/2019/07/23/std-format-cpp20.html

FWIW {fmt} already supports formatting of containers, tuples and ranges as of version 5.0 (https://github.com/fmtlib/fmt/releases/tag/5.0.0), for example:

  #include <fmt/ranges.h>

  std::vector<int> v = {1, 2, 3};
  fmt::print("{}", v); // prints {1, 2, 3}

A lot of work has been done since 2017: the proposal is at its 9th revision (http://fmtlib.net/D0645R9.html) and is prioritized (but not accepted yet) for C++20.

You don't have to use Doxygen with Sphinx although you can.

Sphinx (http://www.sphinx-doc.org) used by Python and some C++ projects like LLVM provides a modern high-quality alternative to Doxygen.

I think Boost was very successful in encouraging development of high-quality libraries that seamlessly work together (most of the time) and have consistent build infrastructure. It is not that important nowadays because the most important parts have already been integrated into the standard library and we have a de facto standard build system (CMake) that makes it easy working with small libraries that do one job well.

Where Boost is a bit lacking is modularity and somewhat varying library quality but this is kind of expected considering the number of subprojects.