System programming in D (Was: The God Language)

[Chad J]

On 12/30/2011 04:13 AM, Walter Bright wrote:
> On 12/30/2011 12:16 AM, Vladimir Panteleev wrote:
>> I agree, but this wasn't as much about heuristics, but compiler
>> capabilities
>> (e.g. inlining assembler functions).
> 
> Adding a keyword won't fix the current problem that the compiler won't
> inline inline assembler functions. It's an orthogonal issue.
> 
> I know there are features on various C compilers to force inlining, I
> know there's a demand for them.
> 
> But I've also, over the years, spent thousands and thousands of hours
> optimizing the hell out of things, so I have some experience with it.
> 
> Once the compiler gets past a certain level of heuristic inlining
> decisions, forcing it to inline more is just chasing rainbows.
> 

When a compiler ISN'T past a certain level of heuristic inlining, then
being able to tell it to inline can save one's ass.

I hit this when writing a flash game.  It was doing the slide-show thing
while on a collision detection broadphase (IIRC) when it went to sort
everything.  The language I was using, haXe, was pretty young at the
time and the compiler probably wasn't inlining well.  BUT, it did have
an inline keyword.  I plopped it down in a few select places and BAM,the
broadphase is ~100x faster and life goes on.  Things were going to get
really damn ugly if I couldn't do that.  (haXe is a pretty cool
language, just not as featureful as D.)

Nonetheless, this is the less important issue...

> And if one really wants to force an inline, one can do things like the C
> memcpy using the preprocessor, or string mixins in D, or even cut&paste.
> If you need to do that in more than a couple places in the code,
> something else is wrong (that old saw about only a tiny percentage of
> the code being a bottleneck is true).
> 
> Also, if you are tweaking at such a level, every compiler is different
> enough that your tweaks are likely to be counterproductive on another
> compiler. Having a portable syntax for such tweaking is not going to help.

This is striking me as becoming a human factors problem.  People want a
way to tell the compiler to inline things.  They are /going/ to get
that, one way or another.  It /will/ happen, regardless of how
experienced /you/ are.  They also may not go about it in entirely
reasonable ways, and then you end up with code optimized for one
compiler that doesn't compile at all on another.  This sucks really bad
for people compiling a program that they didn't write.

And to me, that's what I worry about most.

...

As an aside, I think that people want forced inlining because it gives
them another tool to tweak with.  My experiences with optimization tend
to suggest I can usually optimize things really well with a few short
cycles of profile->experiment->profile.  I don't think I've ever really
/needed/ to dive into assembly yet.  My ventures into the assembler have
been either purely recreational or academic in nature.  Now, something
like an inline feature can help a lot with the "experiment" part of the
cycle.  It's just another knob to twist and see if it gives the result
you want.  Portability be damned, if it gets the thing out the door, I'm
using it!  But, I kind of hate that attitude.  So it's much more
comforting to be able to twist that knob without sacrificing portability
too.  I wouldn't expect it to run as fast on other compilers; I /would/
expect it to compile and run correctly on other compilers.  And if
enregistering variables is more important, then we might want to have a
way to enregister variables too.