View mode: basic / threaded / horizontal-split · Log in · Help
December 30, 2011
Re: System programming in D (Was: The God Language)
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.

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.
December 30, 2011
Re: System programming in D (Was: The God Language)
On 30/12/11 9:13 AM, Walter Bright wrote:
> 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).

When you are writing really performance sensitive code, that old adage 
is certainly *not* true.

It only happens in practice when you don't care that much about 
performance. When you really care, you've already optimised those hot 
spots, so what you end up with is a completely flat profile: no part of 
the program is the bottleneck, but the whole thing is.

At that point, you're likely suffering a death from a thousand cuts: no 
single part of your program is the bottleneck; your poor performance is 
just the sum total of a bunch of small performance penalties here and there.

A perfect example of this is vector operations. Games use vector 
operations all over the place, so their impact on performance is spread 
out over the entire program. You'll never see a dot product or vector 
addition routine at the top of a profile chart, but it will certainly 
affect performance!
December 30, 2011
Re: System programming in D (Was: The God Language)
> 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.

More specifically a distinction would be nice like gcc does:

"-finline-small-functions
Integrate functions into their callers when their body is smaller than  
expected function call code (so overall size of program gets smaller). The  
compiler heuristically decides which functions are simple enough to be  
worth integrating in this way.

Enabled at level -O2.

-finline-functions
Integrate all simple functions into their callers. The compiler  
heuristically decides which functions are simple enough to be worth  
integrating in this way.

Enabled at level -O3."
December 30, 2011
Re: System programming in D (Was: The God Language)
On Friday, 30 December 2011 at 09:13:05 UTC, Walter Bright wrote:
> 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.

Which is exactly why I think an inlining pragma/attribute should 
provide a guarantee, and not a hint. It's a web of 
assumptions/guarantees: asm blocks provide their guarantees, but 
using them introduces new assumptions, that e.g. force-inlining 
solidifies, etc.

Back to the macros vs.

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

D has nothing from the above that's elegant and maintainable. 
Timon's solution comes close, but it uses a DSL to make up for 
what the language doesn't provide.

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

What about the context of creating an optimized library, as 
opposed to optimizing one application?
December 30, 2011
Re: System programming in D (Was: The God Language)
On Friday, 30 December 2011 at 12:00:07 UTC, Vladimir Panteleev 
wrote:
> Back to the macros vs.

Oops, didn't mean to send that. I was going to write that 
comparing C macros with __forceinline functions is much more of a 
level comparison.
December 30, 2011
Re: System programming in D (Was: The God Language)
On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
> On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr wrote:
>> ** The X template
>
> Good work, but I'm not sure if inventing a DSL to make up for the
> problems in D string mixins that C macros don't have qualifies as "doing
> it right".

It certainly does. That is how all my code generation looks like. The 
fact that I am using string mixins to solve some problems shows that 
those are not 'problems in D string mixins'.
December 30, 2011
Re: System programming in D (Was: The God Language)
On Friday, 30 December 2011 at 12:05:27 UTC, Timon Gehr wrote:
> On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
>> On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr 
>> wrote:
>>> ** The X template
>>
>> Good work, but I'm not sure if inventing a DSL to make up for 
>> the
>> problems in D string mixins that C macros don't have qualifies 
>> as "doing
>> it right".
>
> It certainly does. That is how all my code generation looks 
> like. The fact that I am using string mixins to solve some 
> problems shows that those are not 'problems in D string mixins'.

Never mind. You're right. I hadn't thought of this before (using 
DSL nesting to avoid breaking token nesting); it's a nice idea. I 
think I'll steal this for my code :)
December 30, 2011
Re: System programming in D (Was: The God Language)
On Fri, 30 Dec 2011 14:00:06 +0200, Vladimir Panteleev  
<vladimir@thecybershadow.net> wrote:

> On Friday, 30 December 2011 at 09:13:05 UTC, Walter Bright wrote:
>> 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.
>
> Which is exactly why I think an inlining pragma/attribute should provide  
> a guarantee, and not a hint. It's a web of assumptions/guarantees: asm  
> blocks provide their guarantees, but using them introduces new  
> assumptions, that e.g. force-inlining solidifies, etc.

I agree @inline (which will probably be an extension) in D should mean  
force-inline.

Ignoring the impossible-to-inline cases (which in time should get better),  
adding @inline is a few minutes of editing.
It will just bypass the cost function and if it is not possible to inline,  
pop error. I don't have enough knowledge of DMD internals
so i am not sure if should go do it, or maybe i need to start somewhere...
December 30, 2011
Re: System programming in D (Was: The God Language)
On Fri, 30 Dec 2011 16:11:54 +0200, Vladimir Panteleev  
<vladimir@thecybershadow.net> wrote:

> On Friday, 30 December 2011 at 12:05:27 UTC, Timon Gehr wrote:
>> On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
>>> On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr wrote:
>>>> ** The X template
>>>
>>> Good work, but I'm not sure if inventing a DSL to make up for the
>>> problems in D string mixins that C macros don't have qualifies as  
>>> "doing
>>> it right".
>>
>> It certainly does. That is how all my code generation looks like. The  
>> fact that I am using string mixins to solve some problems shows that  
>> those are not 'problems in D string mixins'.
>
> Never mind. You're right. I hadn't thought of this before (using DSL  
> nesting to avoid breaking token nesting); it's a nice idea. I think I'll  
> steal this for my code :)

For me, mixin sounds much more intuitive than inline for what we are  
trying to achieve with force-inline.
If it was user friendly now that would be awesome.
December 30, 2011
Re: System programming in D (Was: The God Language)
On 12/30/2011 4:05 AM, Timon Gehr wrote:
> It certainly does. That is how all my code generation looks like. The fact that
> I am using string mixins to solve some problems shows that those are not
> 'problems in D string mixins'.

I your solution to parameterized strings is very nice. Can you write a brief 
article about it? This should be more widely known.
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home