4 ms·
> `memcpy` is insufficient because it's a copy and that's a huge performance issue. Compilers (at least clang and gcc) are smart enough to see through those me
by FartyMcFarter 8y ago
> `memcpy` is insufficient because it's a copy and that's a huge performance issue.
Compilers (at least clang and gcc) are smart enough to see through those memcpy's. For example:
https://godbolt.org/g/5L5PT5 https://godbolt.org/g/5L5PT5
- AnIdiotOnTheNet 8y agoMaybe, but wouldn't you rather be explicit so you know the compiler will do what you want instead of crossing your fingers and hoping it does?
- camgunz 8y agoFor stack allocated scalars sure. What about stuff on the heap or arrays and structs?
- comex 8y agoGenerally speaking, if a memcpy's size argument is a constant expression equal to the size of a native integer type, it will be transformed to a native load from the source pointer followed by a store to the destination pointer. After that, the load or store operation (or both) may itself be optimized away if the pointer points to a local variable. Thus, for example, given something like: void write32(int *ptr, int val) { memcpy(ptr, &val, 4); } …the load is removed entirely, and the store is kept but becomes a native store: write32: mov DWORD PTR [rdi], esi ret Godbolt link: https://godbolt.org/g/HYv24F https://godbolt.org/g/HYv24F
- Gibbon1 8y ago> Compilers (at least clang and gcc) are smart enough to see through those memcpy's That's worse though because compiler optimization are wholly unreliable. Maybe today, maybe not tomorrow. And you have utterly no control over that.