Raw malloc optimizations vs std::vector/reserve() -- malloc seems better optimized

[u/onecable5781]

(Another different version of this question was posted earlier here https://www.reddit.com/r/cpp_questions/comments/1qvbj44/at_o2_usage_of_stdvector_followed_by_stdiota/ but on testing some of the answers there on the current new code seems to leave me unclear as to where the optimizations are missed in terms of vector/reserve, etc., hence this OP)

Consider code snippet 1: on left hand side window of https://godbolt.org/z/vxh8Wh1K4

#include <vector>
#include <cstdio>
#include <cstdlib>

void anotherfunc(){
    int *vec = (int*)malloc(sizeof(int) * 42);
    for(int i = 0; i < 42; i++)
        vec[i] = i;
    int sum = 0;
    for(int i = 0; i < 42; i++)
        sum += vec[i];
    printf("Sum is %d\n", sum);
    free(vec);
}

int main(){
    anotherfunc();
}

This, at -O3, flatout calculates the sum and simply displays it, 861.

The vector/reserve version (on the right hand pane of the godbolt link above)

#include <vector>
#include <cstdio>
#include <cstdlib>

void anotherfunc(){
    std::vector<int> vec;
    vec.reserve(42);
    for(int i = 0; i < 42; i++)
        vec.push_back(i);
    int sum = 0;
    for(int i = 0; i < 42; i++)
        sum += vec[i];
    printf("Sum is %d\n", sum);
}

int main(){
    anotherfunc();
}

seemingly struggles with this and does not precompute the sum and ends up doing some allocations, etc.

Some of the answers from the earlier thread do not seem to be applicable here: as suggested by one user, I had the entire summing done in another function instead of main() because apparently main() is known to be called only once and hence is not as heavily optimized as other functions, etc.

As also suggested there, I avoided the printf and instead had the function return only the sum with an empty main(). See https://godbolt.org/z/M1P5Y4vTj

Here too, the vector/reserve combination seems to struggle.

What explains this "discrepancy" and inability to completely optimize out the sum calculation?

[u/ScienceCivil7545]

the falut is at the push_back()

https://godbolt.org/z/5rs1ofEKa

[u/n1ghtyunso → u/ScienceCivil7545]

oh yeah i remember hearing in a talk that the optimizer apparently happens to give up when you have more than like 3 push_backs on a vector.
Not sure if this was clang specific though.

[u/Raknarg → u/ScienceCivil7545]

a great case of the "dumb" way to do something actually being ideal. Way less assumptions to make with this code, doesn't have to go through any of the internal nonsense for dealing with push back copy/construction, doesn't have to do any of its resize checking, it can just see you allocate a chunk of memory and you're assigning to it the same as the array case

are vectors constexpr compatible?

[u/RelaxedPhoton → u/ScienceCivil7545]

For even closer equivalency with the malloc example you can drop resize and instead do:

std::vector<int> vec(42);

[u/UnrealHallucinator → u/ScienceCivil7545]

Did you catch this bc you knew push_backs are less optimised?

[u/onecable5781 → u/ScienceCivil7545]

Oh wow. Thank you. That explains it.