1

I hope this isn't a duplicate, since similar questions have been asked. I am concerned about the use of std::memcpy when gcc decides to use the libc's implementation. This probably does not happen, if we use std::copy instead, that is, we avoid this function call into libc? And if so, how does the generated code compare to the libc's implementation of std::memcpy?

Community
  • 1
  • 1
user1095108
  • 14,119
  • 9
  • 58
  • 116
  • I wonder wheterh this should be closed as too broad. It doesn't mention input or output ranges, element type, etcetera. – MSalters Sep 06 '16 at 08:09
  • I do mention element type, ranges are arbitrary. – user1095108 Sep 06 '16 at 08:10
  • `std::copy` works on the principle of `type system` and `std::memcpy` purely works on bytes. It will be tedious and not so clean to use `std::memcpy` inside `std::copy` after evaluating/examining the parameters of `std::copy`. – sameerkn Sep 06 '16 at 08:12
  • @sameerkn I know all that, but it needs to support chars also, just like memcpy. I am asking about avoiding the function call into libc and if the generated code is crappy or good. – user1095108 Sep 06 '16 at 08:14
  • If you see the possible implementation (std::copy)[http://en.cppreference.com/w/cpp/algorithm/copy] then you will find that its better to avoid `memcpy` altogether, since elements are assigned/copied using `operator=`. – sameerkn Sep 06 '16 at 08:17
  • @sameerkn: it may be tedious and not so clean, but providers of standard algorithms do it anyway, because it's fast. – Steve Jessop Sep 06 '16 at 08:20
  • @sameerkn I need to copy bytes fast and the call into libc was a sore in my eye, that's why I asked the question. – user1095108 Sep 06 '16 at 08:22
  • @user1095108: the reason gcc calls into libc is that it thinks it's faster. If the real question is "what's faster" then see http://stackoverflow.com/questions/4707012 – Steve Jessop Sep 06 '16 at 08:23
  • @SteveJessop I just wanted to avoid the branch without writing my own `memcpy()`, which, I suppose, is commendable. – user1095108 Sep 06 '16 at 08:25

3 Answers3

2

Not quite a dupe question, but here is an example of g++ calling memmove or memcpy as part of the implementation of std::copy.

In short no, using std::copy does not in general prevent GCC from using libc.

If you really want to block the optimization then there might be some combination of compiler options that does it, I don't know. You'd have to look into exactly how std::copy is implemented, they might just happen to have written it in a way that it can't be disabled.

Community
  • 1
  • 1
Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
2

It doesn't really matter, or help depending on your perspective.

std::copy is, in at least one standard library implementation I know of, implemented in such a way that it detects if its inputs are contiguous iterators over trivially copyable types, and will just use std::memmove in that case anyway. And the compiler may even recognize that the ranges passed are distinct and will replace that with a memcpy in turn.

In other words, you can switch to std::copy, but chances are the compiler will just switch it back.

Sebastian Redl
  • 69,373
  • 8
  • 123
  • 157
1

std::memcpy is typically a std namespace wrapper around the C memcpy.

Since most modern C libraries provide highly optimised implementations of this function, including restrict pointer arguments - a keyword not available in C++11/14 - it's probably more efficient. If the compiler can prove std::copy operates on distinct ranges, it might also use something like a __builtin_memcpy for gcc. The elements would probably still be required to satisfy the is_trivially_copyable type trait, for example.

The exception may be if you are using std::copy on very short ranges, and the compiler can't deduce the range length at compile time, but still generates a mem[cpy|move] call. I would still be sceptical that any call overhead to a memcpy implementation would be significant. You'd need to look at profiling.

Brett Hale
  • 21,653
  • 2
  • 61
  • 90
  • It's just disturbing to me, I'd prefer and inlined memcpy, but gcc emits a call into libc, still no worries, I can copy&paste a good implementation in there, there are many good ones out there. `std::copy` is much more than a simple wrapper, according to my experience and of some other people, often it is more efficient. – user1095108 Sep 06 '16 at 10:35
  • @user1095108 - if you look at the implementations for `memcpy` in say [`glibc`](https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86_64/multiarch;h=a580c13d7c24f8060128526603c386f7410ea695;hb=fdfc9260b61d3d72541f18104d24c7bcb0ce5ca2) (assuming you're using x86-64, though there are other architectures), you can see that there are highly optimised assembly implementations, with variants for SSE/AVX, etc., covering `memcpy`, `memmove`, etc. I still don't really understand *why* this bothers you so much. If you provided an example where this a problem, the answers would be less vague. – Brett Hale Sep 06 '16 at 11:47