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.
