Comment 0 for bug 656980

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