On Saturday, 10 March 2012 at 12:35:14 UTC, bearophile wrote:
> F i L:
>
>> I sorta figured D would implicitly attribute "static" to nested functions if the function didn't use any variables outside it's scope. Is that not so?
>
> I don't think DMD does that. Before assuming DMD performs one optimization, go to read some of the asm it produces.

Oh you crazy compiler developers. Thinking everyone can read ASM ;-)


>> Why are you saying it's a good idea to use "static" exactly?
>
> Some answers here:
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=160469

Thanks. Pretty much what I thought. Though, there *could* be area for automatic optimization here, right? I mean, DMD could analyze the nested function and deem it worthy of the same optimizations static nested functions receive, correct?

F i L:

> Oh you crazy compiler developers. Thinking everyone can read ASM ;-)

I'd love to be able to develop compilers, but I am not that good yet :-)

Writing working asm is much simpler than writing efficient asm code (more efficient than compiler generated one, even for SIMD code where compilers are still quite bad). And reading asm is much simpler than writing it. And scanning asm code visually to look for simple things, is simpler than reading and understanding what each asm instruction does. Writing very efficient asm isn't a common skill today, but reading a bit of asm is something you learn in a matter of some days if you have the desire, the time, and the right books. Most asm does is simple arithmetic, updating some CPU flags, and moving variables from here to there, where most CPUs manage the cache levels transparently (manually managed Scratchpad cache memory us uncommon). Modern CPUs have accumulated tons of cruft, but at the base it's easy stuff.


> Though, there *could* be area for automatic optimization here, right?

Currently DMD devs are mostly trying to fix bugs, instead of adding optimizations.

And as the pure attribute it's not just a matter of optimization. It's a contract between programmer and compiler. If you add "static" and then you use a variable in the enclosing function, you receive a compilation error. This error can't happen if "static-ness" is just an invisible automatic compiler optimization. It's good for such errors to come out, because when you use static you are stating you don't want to use outer function variables. So this is both a guaranteed optimization and a way to avoid using by mistake a variable defined in the enclosing scope. Using unwillingly variables from the outer scopes is a common source of bugs.

Bye,
bearophile

bearophile wrote:
> Writing working asm is much simpler than...

Ya I've actually written ASM GPU shaders in the past. Not the same instruction set as x86 or anything, but I know the basic concept.


>> Though, there *could* be area for automatic optimization here, right?
>
> Currently DMD devs are mostly trying to fix bugs, instead of adding optimizations.
>
> And as the pure attribute it's not just a matter of optimization. It's a contract between programmer and compiler. If you add "static" and then you use a variable in the enclosing function, you receive a compilation error. This error can't happen if "static-ness" is just an invisible automatic compiler optimization. It's good for such errors to come out, because when you use static you are stating you don't want to use outer function variables. So this is both a guaranteed optimization and a way to avoid using by mistake a variable defined in the enclosing scope. Using unwillingly variables from the outer scopes is a common source of bugs.

Well, my point wasn't that any function could receive "static" or purity implicitly, only nested ones. Seeing as how their use scope is very limited.