System programming in D (Was: The God Language)

[Don]

On 29.12.2011 12:19, Vladimir Panteleev wrote:
> On Thursday, 29 December 2011 at 09:16:23 UTC, Walter Bright wrote:
>> Are you a ridiculous hacker? Inline x86 assembly that the compiler
>> actually understands in 32 AND 64 bit code, hex string literals like
>> x"DE ADB EEF" where spacing doesn't matter, the ability to set data
>> alignment cross-platform with type.alignof = 16, load your shellcode
>> verbatim into a string like so: auto str = import("shellcode.txt");
>
> I would like to talk about this for a bit. Personally, I think D's
> system programming abilities are only half-way there. Note that I am not
> talking about use cases in high-level application code, but rather
> low-level, widely-used framework code, where every bit of performance
> matters (for example: memory copy routines, string builders, garbage
> collectors).
>
> In-line assembler as part of the language is certainly neat, and in fact
> coming from Delphi to C++ I was surprised to learn that C++
> implementations adopted different syntax for asm blocks. However,
> compared to some C++ compilers, it has severe limitations and is D's
> only trick in this alley.
>
> For one thing, there is no way to force the compiler to inline a
> function (like __forceinline / __attribute((always_inline)) ).
[snip]
> Personally, I don't think D qualifies as a true "system programming
> language" in light of the above. It's more of a compiled language with
> pointers and assembler.

I don't think the situation is any different with DMC. I think that if D 
isn't a systems programming lanugage, neither is C or C++ without 
vendor-specific extensions.

But it doesn't really matter -- the main conclusion is still correct: D 
is missing some features which could improve performance considerably.

Before you disagree with any of the above, first
> (for starters) 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 . It doesn't even
> use inline assembler or compiler intrinsics.

Note that the memcpy described there is _far_ from optimal. Memcpy is 
all about cache effciency. DMD translates memcpy to the single 
instruction "rep movsd" which you'd think would be optimal, but you can 
actually beat it by a factor of four or more for long lengths.