By combining all your suggestions, I got at most a 16% speed-up. Great!

I had a good talk with another C++ guru, and he also suggested that we should always hint about the expected memory usage with reserve(), and when possible to use resize(). Which is exactly the same thing that you said. This is a good practice but I won’t include it in the blog results mainly because this is somehow specific to the used algorithm and we are doing benchmarks for a completely generic use-case. I’ll add a note about this at the page though.

Passing by reference is by far the most obvious optimization and every C/C++ developer must use it whenever possible. I’ve updated my source code, even though this is a feature not present in the script languages.

is the 10% you gain by pre-allocation as I said
best

#include<vector>
#include<algorithm>
#include<iostream>
#include<cmath>

using namespace std;

void get_primes7( int n, std::vector<int>& res ) {

    if (n < 2) {
        res.resize(0);
        return;
    }

    if (n == 2) {
        res.resize(1);
        res[0] = 2;
        return;
    }
    
    res.resize(0);   
    std::vector<int> s;
    size_t j = 0;
	
    s.resize( static_cast<int>(n/2.0) );
    for (int i = 3; i < n + 1; i += 2, ++j) s[j] = i;
    s.resize(j);
        
    /* Alternatively: */
    //s.reserve( static_cast<int>(n/2.0)  );
    //for (int i = 3; i < n + 1; i += 2) s.push_back(i);

    int mroot = sqrt(n);
    int half = static_cast<int>(s.size());
    int i = 0;
    int m = 3;

    while (m <= mroot) {
        if (s[i]) {
            int j = static_cast<int>(0.5*(m*m - 3));
            s[j] = 0;
            while (j < half) {
                s[j] = 0;
                j += m;
            }
        }
        i++;
        m = 2*i + 3;
    }

    res.push_back(2);
    std::vector<int>::iterator pend = std::remove (s.begin(), s.end(), 0);
    res.insert(res.begin()+1, s.begin(), pend);               
}

int main() {
    std::vector<int> res;
    for (int i = 1; i <= 10; ++i) {
        get_primes7(10000000, res);       
        std::cout << "Number of primes " << res.size() << "\n";
    }
    return 0;
} 

Nice reply. Thanks. I understand your point. However, even you want a second vector, I made some crucial changes in that implementation that optimize a lot your code (30%). Actually, the pre allocation of the answer only made the code 10% faster in comparison to things I will show in this message

“2. Operator [] is faster than push_back() — ditto. However, this requires an array with a predefined size, correct?”.

That is the most imp optimization !!! The difference between push_back and operator [] can be huge for two reasons. First, push_back does SEVERAL reallocation. (you started from size 0 and every time it does a new allocation, C++ doubles the vector size. So the vector needs ~log2(10000000) to allocate 100000. Resize, on the other hand, will allocate memory only once. Second, push_back is a function and there is more calling overhead than operator. To avoid the first problem, you could reserve memory for s first using the .reserve() member function. Then, you would only have the push_back calling overhead. Another option If you dont know how many iterations you will have (in your case it was easy to calculate but pretend it is not): you can resize the vector with a bigger size first and then, shrink to the size after the loop, as I did. Shrink a vector with resize() does not change its capacity. It only moves the pointer .end().

About 3. Not sure here, but I saw places in my own research code where it made a huge difference. Division takes almost 30 cycles to calculate. Multiplication can be done in 1.

Another point : you were coding by yourself things that are better optimized in the standard. For example. If you really want a second vector. Then the last step could be something like

res.push_back(2);
std::vector::iterator pend = std::remove (s.begin(), s.end(), 0); 
res.insert(res.begin()+1, s.begin(), pend);

Insert is much faster than a loop with push_back, because, as I said before, the latter will do log2(10000000) reallocations. Insert, on the other hand, will only allocate once. But even if you reserve memory first, insert is faster than hand coded loop. Lemma is: standard is always better!

Last, do not pass a vector by value. It is rule 1 of C++. Create a second vector, ok. But the first one you pass as a reference argument and resize to zero to reset it at each call (in the first line of the function you resize it to zero – resize to zero maintains its old capacity!)

If you follow this, your code will speed up by 25%-30% even with a second vector! ( I tested this)

Last comment: I completely understand your points, but to be fair with C++ you could made an observation that it is still possible to speed up the code using pre-allocation (10% more over the 30% you gain by following the points I wrote in this comment). I say this because the other languages you tested dont offer this choice and this is a great advantage of C++. Java is great because of its libraries, Python is great because it is easy and has awesome libraries. C++ is great because allows you to control low level things like memory. If you code C++ like you code Java, then you may think that Java is almost as fast as C++ and that is really not the case. Or you can think that C is much faster, which is also not the case. When you are comparing language, it is important to try to get the best of each language. And note that I did not made any hard core template code. I just changed your implementation a little bit.

[begin quote]
This is a fair competition with fair rules — every language uses the very same algorithm. I know that the algorithm can be adjusted/optimized specifically for each language, but that’s not the point. The idea is, if we used another algorithm which *did* require that we use dynamic arrays everywhere, to compare how each language does the job in regards to performance. Hence I didn’t try to think if I can optimize the algorithm in any language (not that I can for all of them). I tried to explain that by “The correctness of the implementation is not so important, as we just want to check how fast the languages perform”. Which in plain English means — we try to use the very same usage pattern, as if the task really required it. So let’s pretend that we really needed the boxing/unboxing, just as we did for the other languages — all languages do the same algorithm complexity using the same (dynamic) structures.
[end quote]

What I find incompatible in your implementation, compared to the other languages:
1. Let’s pretend that we needed the second vector — just as we have it in all other implementations. If we weren’t implementing the Sieve of Eratosthenes algorithm, we may have needed it for something else. The idea here is to see how languages operate with two different arrays.
2. Pre-allocation of memory/heap/array-size is not what we were after. As already mentioned, we want to see how each language manages to allocate memory in a dynamic way.

The other proposed changes are good points:
1. static_cast() — if that’s faster, we should use it indeed.
2. Operator [] is faster than push_back() — ditto. However, this requires an array with a predefined size, correct?
3. Replace division /2 by mult. 0.5 — does this really make any difference?

In a nutshell, we could use the static_cast() and the division trick, in order to speed up the original C++ algorithm, and at the same time to keep it comparable with other languages, right?

Another thing to remember: push_back is slower than operator [] even when there is no reallocation!!!

Here is my code

#include 
#include 
#include 
#include 

void get_primes7( int n, std::vector& res ) {

	if (n < 2) {
		res.resize(0);
		return;
	}

	if (n == 2) {
		res.resize(1);
		res[0] = 2;
		return;
	}
	
	// we dont need a second vector
	res.resize( static_cast(n/2.0) );       // resize vector only changes .end() 
                                                //  iterator. because we have enough capacity
                                                // it does NOT allocate or deallocate heap memory	
	size_t j = 0;
	for (int i = 3; i < n + 1; i += 2, ++j) res[j] = i;  // operator [] is faster than push_back 
	res.resize(j); // Now we need the correct size for the algorithm below

	int mroot = sqrt(n);
	int half = static_cast(res.size()); // static_cast is always better than reinterpret cast!
	int i = 0;
	int m = 3;

	while (m <= mroot) {
		if (res[i]) {
			int j = static_cast(0.5*(m*m - 3)); // inside a loop, replace division /2 by mult. 0.5
			res[j] = 0;
			while (j < half) {
				res[j] = 0;
				j += m;
			}
		}
		i++; 
		m = 2*i + 3;
	}

        res.push_back(2);
	std::vector::iterator pend  = 
        std::remove (res.begin(), res.end(), 0);  // remove does not change capacity
			                          // or size. Only reorder the vector and returns the 
			                          // iterators that points to the 
		                                  // last non zero position
	res.resize(pend-res.begin()); // again - no allocation or reallocation of memory!
}

int main() {
	std::vector res;
	res.reserve(10000001);  // after you reserve memory, resize() only plays with its internal 
                                // pointers as long as it does not exceed vector previous capacity
	for (int i = 1; i <= 10; ++i) {
		get_primes7(10000000, res);		
		std::cout << "Found " << res.size() << " prime numbers.\n"; 
	}

	return 0;
}

In the Ubuntu setup, I manually made the first partiton of free space of about 100 MB with a mount point of /boot (in my case, was /dev/sda3). Made remaining partitions for / (using most of the free space) and for swap (using a few gigs), then used the drop-down menu to select /dev/sda3 (where /boot would be installed) for installing GRUB, rather than /dev/sda.

And you don’t need to install S2Mon on a server of yours, as opposed to Munin or Nagios (thus you have less expenses, zero maintenance, etc).