On Thursday, 29 December 2011 at 19:47:39 UTC, Walter Bright
wrote:
On 12/29/2011 3:19 AM, Vladimir Panteleev wrote:
I'd like to invite you to translate Daniel Vik's C memcpy
implementation to D:
http://www.danielvik.com/2010/02/fast-memcpy-in-c.html
Challenge accepted.
Ah, a direct translation using functions! This is probably the
most elegant approach, however - as I'm sure you've noticed - the
programmer has no control over what gets inlined.
Examining the assembler output, it inlines everything except
COPY_SHIFT, COPY_NO_SHIFT, and COPY_REMAINING. The inliner in
dmd could definitely be improved, but that is not a problem
with the language, but the implementation.
This is the problem with heuristic inlining: while great by
itself, in a position such as this the programmer is left with no
choice but to examine the assembler output to make sure the
compiler does what the programmer wants it to do. Such behavior
can change from one implementation to another, and even from one
compiler version to another. (After all, I don't think that we
can guarantee that what's inlined today, will be inlined
tomorrow.)
Continuing in that vein, please note that neither C nor C++
require inlining of any sort. The "inline" keyword is merely a
hint to the compiler. What inlining takes place is completely
implementation defined, not language defined.
I think we can agree that the C inline hint is of limited use.
However, major C compiler vendors implement an extension to force
inlining. Generally, I would say that common vendor extensions
seen in other languages are an opportunity for D to avoid a
similar mess: such extensions would not have to be required to be
implemented, but when they are, they would use the same syntax
across implementations.
I wish to note that the D version semantically accomplishes the
same thing as the C version without using mixins or CTFE - it's
all straightforward code, without the abusive preprocessor
tricks.
I don't think there's much value in that statement. After all,
except for a few occasional templates (which weren't strictly
necessary), your translation uses few D-specific features. If you
were to leave yourself at the mercy of a C compiler's optimizer,
your rewrite would merely be a testament against C macros, not
the power of D.
However, the most important part is: this translation is
incorrect. C macros in the original code provide a guarantee that
the code is inlined. D cannot make such guarantees - even your
amended version is tuned to one specific implementation (and
possibly, only a specific range of versions of it).
