System programming in D (Was: The God Language)

[Vladimir Panteleev]

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).