System programming in D (Was: The God Language)

[Walter Bright]

On 12/29/2011 9:51 PM, Vladimir Panteleev wrote:
> 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.

The programmer also has no control over which variables go into which registers. 
(Early C compilers did provide this.)


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

I know.


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

I think this criticism is off target, because the C example was almost entirely 
macros - and macros that were used in the service of evading C language 
limitations. The point wasn't to use clever D features, the challenge was to 
demonstrate you can get the same results in D as in C.


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

I also think this is off target, because a C compiler really doesn't guarantee 
**** about efficiency, it only guarantees that it will work "as if" it was 
executed on some idealized abstract machine. Even dividing code up into 
functions is completely arbitrary, and open to wildly different strategies that 
are perfectly legal to any C compiler. A C compiler doesn't have to enregister 
anything in variables, either, and that has far more of a performance impact 
than inlining.

There are a very wide range of code generation techniques that compilers employ. 
All of them, to verify that they are being applied, require inspection of the 
assembler output. Many argue that the compiler should tell you about inlining - 
but what about all those others? I think the focus on inlining (as opposed to 
other possible optimizations) is out of proportion, likely exacerbated by dmd 
needing to do a better job of it.

I completely agree that DMD's inliner is underpowered and needs improvement. I 
am less sure that this demonstrates that the language needs changes.

Functions below a certain size should be inlined if possible. Those above that 
size do not benefit perceptibly from inlining. Where that certain size exactly 
is, who knows, but I doubt that functions near that size will benefit much from 
user intervention.