On 2012-02-22 00:13, Manu wrote:
> On 21 February 2012 23:06, Jacob Carlborg <doob@me.com
>     Well, that's not what happen with templates.
>
>
> ... really? why?
> You've just made me very very scared for my simd module :/

I've answered to this in an answer to Michel's answer.

> I've had a serious concern about D's lack of a force-inline for quite a
> while...

-- 
/Jacob Carlborg

On 2012-02-22 07:41:21 +0000, Jacob Carlborg <doob@me.com> said:

> void foo (T) () {}
> void main ()
> {
>      foo!(int);
>      foo!(char);
> }
> 
> $ dmd -inline -O -release main.d
> $ nm main | grep foo
> 
> 00000001000012b8 T _D4main10__T3fooTaZ3fooFZv
> 00000001000012b0 T _D4main10__T3fooTiZ3fooFZv
> 
> Outputs two symbols as expected, one for each instantiation.

That's expected indeed.

This doesn't mean the inliner will not inline the templates. In fact, if you correct the example and look at the assembler output you'll see it will (in your example there is nothing to inline since you're just instantiating the template without calling it).

What doesn't happen is stripping the unreferenced symbols from the executable. On OS X, try adding "-L-dead_strip" to DMD's argument to instruct the linker to do so.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2012-02-22 13:53, Michel Fortin wrote:
> On 2012-02-22 07:41:21 +0000, Jacob Carlborg <doob@me.com> said:
>
>> void foo (T) () {}
>> void main ()
>> {
>> foo!(int);
>> foo!(char);
>> }
>>
>> $ dmd -inline -O -release main.d
>> $ nm main | grep foo
>>
>> 00000001000012b8 T _D4main10__T3fooTaZ3fooFZv
>> 00000001000012b0 T _D4main10__T3fooTiZ3fooFZv
>>
>> Outputs two symbols as expected, one for each instantiation.
>
> That's expected indeed.
>
> This doesn't mean the inliner will not inline the templates. In fact, if
> you correct the example and look at the assembler output you'll see it
> will (in your example there is nothing to inline since you're just
> instantiating the template without calling it).
>
> What doesn't happen is stripping the unreferenced symbols from the
> executable. On OS X, try adding "-L-dead_strip" to DMD's argument to
> instruct the linker to do so.
>

1. The example is correct, you can call a method without parentheses
2. Adding -L-dead_strip does not seem to strip the "foo" symbols
3. Adding -L-dead_strip causes a segmentation fault with this example (DMD 2.057)

import std.stdio;

void foo (T) () { writeln("asd"); }
void main ()
{
     foo!(int);
     foo!(char);
}

4. I thought the reason for the big executable using the Objective-C/D bridge was due to all these template symbols.

-- 
/Jacob Carlborg

On Wed, Feb 22, 2012 at 06:32:14PM +0100, Jacob Carlborg wrote: [...]
> 1. The example is correct, you can call a method without parentheses
[...]

This is not directly related, but isn't calling methods without parentheses deprecated, unless it's marked @property? I thought we will soon enforce @property.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius

On 2012-02-22 17:32:14 +0000, Jacob Carlborg <doob@me.com> said:

> On 2012-02-22 13:53, Michel Fortin wrote:
>> On 2012-02-22 07:41:21 +0000, Jacob Carlborg <doob@me.com> said:
>> 
>>> void foo (T) () {}
>>> void main ()
>>> {
>>> foo!(int);
>>> foo!(char);
>>> }
>>> 
>>> $ dmd -inline -O -release main.d
>>> $ nm main | grep foo
>>> 
>>> 00000001000012b8 T _D4main10__T3fooTaZ3fooFZv
>>> 00000001000012b0 T _D4main10__T3fooTiZ3fooFZv
>>> 
>>> Outputs two symbols as expected, one for each instantiation.
>> 
>> That's expected indeed.
>> 
>> This doesn't mean the inliner will not inline the templates. In fact, if
>> you correct the example and look at the assembler output you'll see it
>> will (in your example there is nothing to inline since you're just
>> instantiating the template without calling it).
>> 
>> What doesn't happen is stripping the unreferenced symbols from the
>> executable. On OS X, try adding "-L-dead_strip" to DMD's argument to
>> instruct the linker to do so.
>> 
> 
> 1. The example is correct, you can call a method without parentheses

Ah, seems I forgot this.

> 2. Adding -L-dead_strip does not seem to strip the "foo" symbols
> 3. Adding -L-dead_strip causes a segmentation fault with this example (DMD 2.057)
> 
> import std.stdio;
> 
> void foo (T) () { writeln("asd"); }
> void main ()
> {
>       foo!(int);
>       foo!(char);
> }

I'm still on v2.055. And I can confirm -L-dead_strip worked for me, but I did a change similar to yours so the template was calling printf (that makes it easier to see if it was inlined when looking at the assembly). Everything worked as expected with printf. Calling writeln, which is a template itself, which could be inlined into foo, could cause foo to not be inlined, although it doesn't explain the segfault.

I'm starting to suspect the empty version of foo doesn't get inlined for some reason.


> 4. I thought the reason for the big executable using the Objective-C/D bridge was due to all these template symbols.

I might have been, but I'd be surprised I didn't try striping the executable to fix the problem.

In the end, mostly all the instantiated code has to be there for the virtual tables. There's almost one instanciation per method, and that is a lot of bloat. Whether the template instanciation is inlined or not just changes under which symbol the code resides, the code doesn't magically disappear, it still has to be there somewhere.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2012-02-22 19:39, Michel Fortin wrote:
> On 2012-02-22 17:32:14 +0000, Jacob Carlborg <doob@me.com> said:
>
>> On 2012-02-22 13:53, Michel Fortin wrote:
>>> On 2012-02-22 07:41:21 +0000, Jacob Carlborg <doob@me.com> said:
>>>
>>>> void foo (T) () {}
>>>> void main ()
>>>> {
>>>> foo!(int);
>>>> foo!(char);
>>>> }
>>>>
>>>> $ dmd -inline -O -release main.d
>>>> $ nm main | grep foo
>>>>
>>>> 00000001000012b8 T _D4main10__T3fooTaZ3fooFZv
>>>> 00000001000012b0 T _D4main10__T3fooTiZ3fooFZv
>>>>
>>>> Outputs two symbols as expected, one for each instantiation.
>>>
>>> That's expected indeed.
>>>
>>> This doesn't mean the inliner will not inline the templates. In fact, if
>>> you correct the example and look at the assembler output you'll see it
>>> will (in your example there is nothing to inline since you're just
>>> instantiating the template without calling it).
>>>
>>> What doesn't happen is stripping the unreferenced symbols from the
>>> executable. On OS X, try adding "-L-dead_strip" to DMD's argument to
>>> instruct the linker to do so.
>>>
>>
>> 1. The example is correct, you can call a method without parentheses
>
> Ah, seems I forgot this.
>
>> 2. Adding -L-dead_strip does not seem to strip the "foo" symbols
>> 3. Adding -L-dead_strip causes a segmentation fault with this example
>> (DMD 2.057)
>>
>> import std.stdio;
>>
>> void foo (T) () { writeln("asd"); }
>> void main ()
>> {
>> foo!(int);
>> foo!(char);
>> }
>
> I'm still on v2.055. And I can confirm -L-dead_strip worked for me, but
> I did a change similar to yours so the template was calling printf (that
> makes it easier to see if it was inlined when looking at the assembly).
> Everything worked as expected with printf. Calling writeln, which is a
> template itself, which could be inlined into foo, could cause foo to not
> be inlined, although it doesn't explain the segfault.
>
> I'm starting to suspect the empty version of foo doesn't get inlined for
> some reason.
>
>
>> 4. I thought the reason for the big executable using the Objective-C/D
>> bridge was due to all these template symbols.
>
> I might have been, but I'd be surprised I didn't try striping the
> executable to fix the problem.
>
> In the end, mostly all the instantiated code has to be there for the
> virtual tables. There's almost one instanciation per method, and that is
> a lot of bloat. Whether the template instanciation is inlined or not
> just changes under which symbol the code resides, the code doesn't
> magically disappear, it still has to be there somewhere.
>

Yes, exactly.

-- 
/Jacob Carlborg

On 2012-02-22 18:40, H. S. Teoh wrote:
> On Wed, Feb 22, 2012 at 06:32:14PM +0100, Jacob Carlborg wrote:
> [...]
>> 1. The example is correct, you can call a method without parentheses
> [...]
>
> This is not directly related, but isn't calling methods without
> parentheses deprecated, unless it's marked @property? I thought we will
> soon enforce @property.

As I understand it, that will most likely be where we're going. But we're not there yet.

-- 
/Jacob Carlborg