"janderson" <askme@me.com> wrote in message news:g0o03o$k01$1@digitalmars.com...
> Nick Sabalausky wrote:
>> "Dee Girl" <deegirl@noreply.com> wrote in message news:g0noqa$2rpf$1@digitalmars.com...
>>> There was long discussion here. Maybe you did not read.
>>>
>>
>> Didn't see it, must have been on a different thread.
>>
>>> void slowbad(delegate void() f)
>>> {
>>>    f();
>>> }
>>>
>>> void fastgood(alias f)()
>>> {
>>>    f();
>>> }
>>>
>>> void main()
>>> {
>>>    void f() { }
>>>    slowbad(&f);
>>>    fastgood!(f);
>>> }
>>>
>>> Syntax is different but power is very different. std.algorithm uses alias always. Everybody else uses slowbad ^_^ Dee Girl
>>
>> Isn't that akin to forcing a function to be inlined? It sounds to me like, just as with normal function inlining, there are cases where that could backfire because of things like increased cache misses or increased register consumption (or are those outdated problems with inlining?).
>
> Only if the compiler decided to inline the contents of f function. Even then if the compiler can inline f's contents, its probably going to beable to reduce the size of the program size somewhat.  Normally the compiler is going to get it right with inlining.  The above template will boil down to:
>
> void main()
> {
>    void f() { }
>    slowbad(&f);  //May or maynot be inlined
>    f();
> }
>
> As you can see f() is one function call less then slowbad and doesn't have to do any of the other stuff slowbad would.
>

But fastgood() is always inlined, right?

Nick Sabalausky wrote:
> "janderson" <askme@me.com> wrote in message news:g0o03o$k01$1@digitalmars.com...
>> Nick Sabalausky wrote:
>>> "Dee Girl" <deegirl@noreply.com> wrote in message news:g0noqa$2rpf$1@digitalmars.com...
>>>> There was long discussion here. Maybe you did not read.
>>>>
>>> Didn't see it, must have been on a different thread.
>>>
>>>> void slowbad(delegate void() f)
>>>> {
>>>>    f();
>>>> }
>>>>
>>>> void fastgood(alias f)()
>>>> {
>>>>    f();
>>>> }
>>>>
>>>> void main()
>>>> {
>>>>    void f() { }
>>>>    slowbad(&f);
>>>>    fastgood!(f);
>>>> }
>>>>
>>>> Syntax is different but power is very different. std.algorithm uses alias always. Everybody else uses slowbad ^_^ Dee Girl
>>> Isn't that akin to forcing a function to be inlined? It sounds to me like, just as with normal function inlining, there are cases where that could backfire because of things like increased cache misses or increased register consumption (or are those outdated problems with inlining?).
>> Only if the compiler decided to inline the contents of f function. Even then if the compiler can inline f's contents, its probably going to beable to reduce the size of the program size somewhat.  Normally the compiler is going to get it right with inlining.  The above template will boil down to:
>>
>> void main()
>> {
>>    void f() { }
>>    slowbad(&f);  //May or maynot be inlined
>>    f();
>> }
>>
>> As you can see f() is one function call less then slowbad and doesn't have to do any of the other stuff slowbad would.
>>
> 
> But fastgood() is always inlined, right? 
> 
> 

You'd have to get Walters for the final word however I can't see why the compiler would generate another function for fastgood other then to speed up compiler performance for duplicate templates.  If your worried about a long fastgood function being inlined, then I suggest that that template has been made to long.  Also pre-premature optimisation is not a good thing.  Do what works for you then optimize later.

In my experience things like using delegates over templates rarely matter.  That is because the size of the rest of the code dwarfs the runtime spent there.  People will run benchmarks on the specific piece of code and get some impressive benchmarks but they don't try running it in real world code.  Many times optimisation works against maintainability and flexibility, yet having highly flexible code is the key to being able to focus optimizations on the code that matters.

Having said that, its nice to have these optimizations in the standard libraries because I figure that with 1000's of users, someones/everyones code is going to benefit from it.

It is also true that heavy use of templates can slow down code speed just as heavy use of delegates.  I think its up to the engineer to make the correct judgment call, particularly after they've run the profiler.


-Joel

janderson Wrote:
> You'd have to get Walters for the final word however I can't see why the compiler would generate another function for fastgood other then to speed up compiler performance for duplicate templates.  If your worried about a long fastgood function being inlined, then I suggest that that template has been made to long.  Also pre-premature optimisation is not a good thing.  Do what works for you then optimize later.

It is not about inlining. I think this is confusion again, same made in discussion with title safer casts. It is about template instantiation. Which can affect inlining but is very different thing.

> In my experience things like using delegates over templates rarely matter.  That is because the size of the rest of the code dwarfs the runtime spent there.  People will run benchmarks on the specific piece of code and get some impressive benchmarks but they don't try running it in real world code.

If you see 4 times faster in a function then all program will not be 4 times faster. Of course. But many programs have little core operation. For example wc has at its core reading file, character comparison and loop. If core has 4 times slower function maybe the cost is much.

> Many times optimisation works against maintainability and flexibility, yet having highly flexible code is the key to being able to focus optimizations on the code that matters.

General observation is correct. But phobos algorithm and compose are good but not inflexible.

> Having said that, its nice to have these optimizations in the standard
> libraries because I figure that with 1000's of users, someones/everyones
> code is going to benefit from it.
> It is also true that heavy use of templates can slow down code speed
> just as heavy use of delegates.  I think its up to the engineer to make
> the correct judgment call, particularly after they've run the profiler.

If you have many template instantiation code is big. Big makes code slow because cache effect. But with template you can limit size because you can write slowbad to use fastgood. Then only one fastgood is instantiated. But if you start with slowbad is nothing you can do. Thank you, Dee Girl

Dee Girl wrote:
> janderson Wrote:
>> You'd have to get Walters for the final word however I can't see why the compiler would generate another function for fastgood other then to speed up compiler performance for duplicate templates.  If your worried about a long fastgood function being inlined, then I suggest that that template has been made to long.  Also pre-premature optimisation is not a good thing.  Do what works for you then optimize later.
> 
> It is not about inlining. I think this is confusion again, same made in discussion with title safer casts. It is about template instantiation. Which can affect inlining but is very different thing.

This was in regards to Nicks question.

> 
>> In my experience things like using delegates over templates rarely matter.  That is because the size of the rest of the code dwarfs the runtime spent there.  People will run benchmarks on the specific piece of code and get some impressive benchmarks but they don't try running it in real world code. 
> 
> If you see 4 times faster in a function then all program will not be 4 times faster. Of course. But many programs have little core operation. For example wc has at its core reading file, character comparison and loop. If core has 4 times slower function maybe the cost is much.

I agree. Read the last paragraph. This is taken out of context.

> 
>> Many times optimisation works against maintainability and flexibility, yet having highly flexible code is the key to being able to focus optimizations on the code that matters.
> 
> General observation is correct. But phobos algorithm and compose are good but not inflexible.

I agree.

> 
>> Having said that, its nice to have these optimizations in the standard libraries because I figure that with 1000's of users, someones/everyones code is going to benefit from it.
>> It is also true that heavy use of templates can slow down code speed just as heavy use of delegates.  I think its up to the engineer to make the correct judgment call, particularly after they've run the profiler.
> 
> If you have many template instantiation code is big. Big makes code slow because cache effect. But with template you can limit size because you can write slowbad to use fastgood. Then only one fastgood is instantiated. But if you start with slowbad is nothing you can do. Thank you, Dee Girl

I agree. Read first paragraph.