| 2010-10-08 17:00:23 |
Lucas Clemente Vella |
description |
Binary package hint: gcc-4.4
According to "/usr/include/c++/4.4.3/bits/stl_algobase.h", on regarding std::copy, "This inline function will boil down to a call to @c memmove whenever possible." But it is not true, you can see in a very simple test:
test_copy.cpp:
int main()
{
int *b1 = new int[1024*1024];
int *b2 = new int[1024*1024];
for(int i = 0; i < 10000; ++i) {
std::copy(b1, b1 + (1024*1024), b2);
std::copy(b2, b2 + (1024*1024), b1);
}
}
teste_mmove.cpp:
int main()
{
int *b1 = new int[1024*1024];
int *b2 = new int[1024*1024];
for(int i = 0; i < 10000; ++i) {
memmove(b2, b1, 1024*1024);
memmove(b1, b2, 1024*1024);
}
}
$ time ./test_copy
real 0m14.060s
user 0m14.040s
sys 0m0.000s
$ time ./test_mmove
real 0m2.310s
user 0m2.310s
sys 0m0.000s
The execution time of std::copy is about 600% of memmove's time in this test (and I don't know why the header file talks about memmove, and not memcpy). It is certainly a bug, because it contradicts what the header says, and there should be no reason to std::copy to be slower than memcpy when applied to bare pointers.
Tested with:
gcc-4.4 - 4.4.3-4ubuntu5
libstdc++6-4.1-dev - 4.1.2-27ubuntu1 |
Binary package hint: gcc-4.4
According to "/usr/include/c++/4.4.3/bits/stl_algobase.h", on regarding std::copy, "This inline function will boil down to a call to @c memmove whenever possible." But it is not true, you can see in a very simple test:
test_copy.cpp:
int main()
{
int *b1 = new int[1024*1024];
int *b2 = new int[1024*1024];
for(int i = 0; i < 10000; ++i) {
std::copy(b1, b1 + (1024*1024), b2);
std::copy(b2, b2 + (1024*1024), b1);
}
}
teste_mmove.cpp:
int main()
{
int *b1 = new int[1024*1024];
int *b2 = new int[1024*1024];
for(int i = 0; i < 10000; ++i) {
memmove(b2, b1, 1024*1024);
memmove(b1, b2, 1024*1024);
}
}
$ time ./test_copy
real 0m14.060s
user 0m14.040s
sys 0m0.000s
$ time ./test_mmove
real 0m2.310s
user 0m2.310s
sys 0m0.000s
The execution time of std::copy is about 600% of memmove's time in this test (and I don't know why the header file talks about memmove, and not memcpy). It is certainly a bug, because it contradicts what the header says, and there should be no reason to std::copy to be slower than memcpy when applied to bare pointers.
Tested with:
gcc-4.4 - 4.4.3-4ubuntu5
libstdc++6-4.4-dev - 4.4.3-4ubuntu5
|
|
