unexpected optimizations

[karatse]

Channel

C++Weekly

Topics

I would love to see some examples where code optimization optimizes "bad" code but not good code. An example that I've observed with -O3:

void print_int(std::ostream &out, int n) {
    out << "The answer is " << n << ".\n";
}

void print_str(std::ostream &out, int n) {
    out << "The answer is " << std::to_string(n) << ".\n";
}

I would expect the first function to be faster or equivalent to the second one which is not the case, at least on the devices I've tested. The second one is up to 5-10% faster depending the std version. Do you know other examples like this?

Length

5-10 minutes

[LB--]

I'd guess it's because std::to_string does not have any formatting options to consider, whereas streams have to consider a wide variety of formatting effects. How did you perform the testing though? Did you use quick-bench?

[karatse]

I think you're right on why the int version is not optimized. I would not expect str to be 10% faster though.

[LB--]

It looks like the operator<<(int) is required to call std::num_put::put which looks significantly more complex than std::to_string. In the generated assembly I notice std::to_string appears to get inlined while the ostream calls are not. As for why it's noticeably faster, I am guessing short string optimization helps a lot - all the std::string manipulation appears to be inlined too, so it can skip dynamic memory allocation for all the numbers that fit in the short string buffer. Meanwhile std::num_put::put appears to use an output iterator, which may be constraining the level of optimization the compiler can perform, especially in context of all the other considerations it has to branch for. I guess this can be bundled in with more reasons to not use the standard stream classes in C++.

[karatse]

Reasons not to use standard streams is not what I was thinking but sounds like a fun video to watch.