View mode: basic / threaded / horizontal-split · Log in · Help
May 18, 2008
Re: C++ vs Lisp
"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?
May 18, 2008
Re: C++ vs Lisp
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
May 18, 2008
Re: C++ vs Lisp
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
May 18, 2008
Re: C++ vs Lisp
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home