Performance in DEBUG mode

[dpronin]

Performance in DEBUG mode

[dpronin]

@DenisYaroshevskiy thank you, indeed so, again from https://en.cppreference.com/w/cpp/algorithm/copy:

In practice, implementations of std::copy avoid multiple assignments and use bulk copy functions such as std::memmove if the value type is TriviallyCopyable and the iterator types satisfy LegacyContiguousIterator.

But actually I see a contradiction in the standard because they preserve a well-defined behaviour for trivially copyable POD types as a special case but warn about everything else to be copied with undefined result. They'd better call memcpy from my point of view to conform their rules and also possibly increase performance. Of course, if they did that they would definitely need to introduce a new algo for copying overlapping objects and memory

Nevertheless, it is quite beside the point of our initial talk

[DenisYaroshevskiy]

Why eve doesn't call memmove

We could but then: a) we loose all the tuning abilities. b) memmove is great, just use memmove.
Generally speaking I wouldn't use eve::algo::copy for just bytes copying.

PSS: Also, be aware, that everything is compiled in -march=native mode that enables everything up to avx512 including

If you use avx512 - I'd recommend to think about frequency scaling https://jfalcou.github.io/eve/freqscale.html - you might get more perf.

[dpronin]

@DenisYaroshevskiy I didn't talk about memmove, though :) Is there misundestanding?)

[DenisYaroshevskiy]

std::copy is calling memmove under the hood, sorry for misunderstaning.

[dpronin]

@DenisYaroshevskiy are you sure? I do not think so, it must not. The ranges must not overlap, but memmove works with possibly overlapping memory. I think std::copy assumes that a source does not intersect a destination.

From https://en.cppreference.com/w/cpp/algorithm/copy

Copies all elements in the range [first, last) starting from first and proceeding to last.
If d_first is in [first, last), the behavior is undefined. In this case, std::copy_backward may be used instead.

Correct me if I am wrong

[DenisYaroshevskiy]

I believe you are, they can overlap one way. And copy_backward are allowed to overlap the other way

In any case: https://github.com/llvm/llvm-project/blob/b0c6fc81fe132f20eed38bd836620dfcb5ac17e9/libcxx/include/__algorithm/copy_move_common.h#L66

And: https://github.com/llvm/llvm-project/blob/b0c6fc81fe132f20eed38bd836620dfcb5ac17e9/libcxx/include/__string/constexpr_c_functions.h#L212