On Saturday, 11 May 2019 at 00:09:08 UTC, Mike Franklin wrote:
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote:
I'm not 100% sure it's a good idea to implement memcpy in D
just to prove that it can be done / just to say that we're
independent of libc. Libc implementations of fundamental
operations, esp. memcpy, are usually optimized to next week
and back for the target architecture, taking advantage of the
target arch's quirks to maximize performance. Not to mention
that advanced compiler backends recognize calls to memcpy and
can optimize it in ways they can't optimize a generic D
function they fail to recognize as being equivalent to memcpy.
I highly doubt a generic D implementation could hope to beat
that, and it's a little unrealistic, given our current
manpower situation, for us to be able to optimize it for each
target arch ourselves.
I understand that point of view. Indeed we have to demonstrate
benefit. One benefit is to not have to obtain a C toolchain
when building D programs. That is actually quite an
inconvenient barrier to entry when cross-compiling (e.g. for
developing microcontroller firmware on a PC).
I'm also hoping that a D implementation would be easier to
comprehend than something like this:
https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S The D implementation still has to handle all of those corner cases, but I'd rather read D code with inline assembly sprinkled here and there than read the entire thing in assembly. The goal with the D implementation would be to minimize the assembly.
For compilers that already do something special with memcpy and
don't require a C standard library, there's no reason to do
anything. My initial exploration into this has shown that DMD
is not one of those compilers.
Also, take a look at this data:
https://forum.dlang.org/post/jdfiqpronazgglrkm...@forum.dlang.org
Why is DMD making 48,000 runtime calls to memcpy to copy 8 bytes
of data? Many of those calls should be inlined. I see
opportunity for improvement there.
Mike
