Best interface for memcpy() (and the string.h family of functions)

[Stefanos Baziotis]

On Wednesday, 29 May 2019 at 18:14:11 UTC, Jonathan Marler wrote:
>
> You didn't answer the question.
>

I don't know how "benchmarks" does not answer a question. For me, 
it's
the most important answer.

> How would inlining the implementation of memcpy be faster? The 
> implementation of memcpy doesn't need to know which types it is 
> copying, so every call to it can have the exact same 
> implementation.  You only need one instance of the 
> implementation.  This means you can fine-tune it, many libc 
> implementations will implement it in assembly because it's used 
> so often and again, it doesn't need to know what types it is 
> copying.  All it needs is 2 pointers a size.  That's why in D, 
> you should only create wrappers that ensure type-safety and 
> bounds checking and then forward to the real implementation, 
> and those wrappers should be inlined but not the memcpy 
> implementation itself.
>
> If you want to provide you own implementation of memcpy you 
> can, but inlining your implementation into every call, when the 
> implementation is truly type agnostic just results in code 
> bloat with no benefit.

It is typed currently, with benefits. It's not the same for every 
type and our
idea is not to just forward the size. By inlining, you can get 
quite better
performance exactly because you inline and you don't just forward 
the size and
because you know info about the type.
Check this: 
https://github.com/JinShil/memcpyD/blob/master/memcpyd.d
And preferably, run it and see the asm generated.
Also, what should be considered is that types give you the info 
about alignment
and different implementations depending on this alignment.