C++ vs Lisp

[janderson]

Nick Sabalausky wrote:
> "janderson" <askme at me.com> wrote in message 
> news:g0o03o$k01$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> "Dee Girl" <deegirl at noreply.com> wrote in message 
>>> news:g0noqa$2rpf$1 at 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