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.
