Take the 2-minute tour ×

I am expecting a std::fill on an continuous container, say std::vector, will automatically compiled to a call of memset. However, when I tried the following code

#include <vector>
#include <algorithm>
#include <numeric>

using namespace std;

int main(void) throw()
    vector<double> vec(300000);



gcc compiled the first std::fill to a simple loop. But I think it could be done by SSE or other advanced vectorized code. Please give me a hint. Thanks.

share|improve this question
Did you compile with optimizations enabled? Also, main shouldn't have an exception-specification. –  GManNickG Feb 22 '11 at 5:15
...or be declared main(void). –  msandiford Feb 22 '11 at 5:23
Just use memset. –  Matt Joiner Feb 22 '11 at 5:30
Requested hint: GCC's open source - knock yourself out. –  Tony D Feb 22 '11 at 7:08
@spong: main(void) is fine. –  GManNickG Feb 22 '11 at 8:28
show 2 more comments

3 Answers

up vote 3 down vote accepted

Addressing your specific example of double, it would have to be a platform specific optimization and most likely g++ decided not to do such a thing. The reason is of course any platforms using a representation of double for which 0.0 does not mean all zero bytes. Nope that additionally, setting to any number OTHER than zero is a whole different game as it's not just setting every byte to zero: There is a specific pattern that needs to be followed. It gets worse with negative numbers.

Unless you have specific profiling information that the fill is taking significantly longer than memset I wouldn't be too worried about it. If it IS taking a lot longer you can either hand-tune to manually use memset or try to address the root cause, the need to set to zero repeatedly.

share|improve this answer
Thanks for the hint. I thought 0.0 stands for all zero bits in some ISO/IEEE standard. I'm working on HPC and my profiler saying fill took about 5% of time. Also, Intel compiler will turn it into __intel_fast_memset. –  xis Feb 22 '11 at 17:25
@xis19 Indeed in IEEE 754 0.0 means all 0 bits, but it's not guaranteed that this representation will be used for all platforms for which C/C++ compilers are available. –  Mark B Feb 22 '11 at 18:18
@MarkB: this doesn't really explain why GCC doesn't do it though. They obviously know which platform they're compiling for, and whether an optimization such as this is safe. –  jalf May 15 '12 at 21:11
add comment

The standard doesn't force implementors to use memset(). But gcc for example does happen to use memset() for std::fill() on containers of char.

share|improve this answer
Yes, that's correct. And Intel Compiler will use __intel_fast_memset for both fill and memset. –  xis Feb 22 '11 at 17:26
add comment

It can, and it's a shame that it usually doesn't. At the very least it would mean an improvement to code size. The problem is that while it's easy enough for a human to spot a memset, there's a huge amount of temporary objects and other cruft generated by that one line, and it's not so easy to optimize.

The shame is that the simple loop is generated because it does at least simplify down to something like:

const T val(0.0);
for (size_t i = 0; i < 30000; ++i) vec.data[i] = double(val);

...but it doesn't make the final deductive leap that a 0..30000 loop through an array of pod types being initialized to the same value is best done with a memset. As mentioned by wilhelmtell, some implementations specialize on a few pod types where there's a large win (looping on chars is slow). I really do wish compilers would make that final leap because it would help uptake of using container libraries in general if people knew this won't happen.

share|improve this answer
Memset fills each byte with the same value. For larger types it would only work if the value of each byte would be the same (for example, it would work for setting an array of ints to 0, but not to an arbitrary value such as 42). - It's not really a question of the smartness of the implementation, because you can only call memset to fill PODs with any value if the size of it is 1. –  UncleBens Feb 22 '11 at 23:30
add comment

Your Answer


