Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> kris wrote:
>>>
>>>> What about (c) how templates are affected at each step ?
>>>
>>>
>>>
>>> It's the same algorithm - nothing special about templates.
>>
>>
>> Is it possible, do you think, to be just a little more forthcoming on this?
>>
>> 1) when you batch-compile code with multiple references to a template, there is just one instance generated.
> 
> 
> Yes.
> 
>> 2) when you compile the same code modules individually, there are presumably multiple template instances generated?
> 
> 
> Yes.
> 
>> 3) how does the linker resolve the multiple template instances to just one?
> 
> 
> The template instantiations are put into COMDAT sections, and the linker discards redundant ones.

Thank you;

4) all symbols required to represent typeinfo and templates are now duplicated in each object file ?

5) The linker does not have to search beyond the current object file for instances of #4 (as suggested by larsivi) ?

6) the result is a library with many more duplicate symbols than before, but arranged in such a manner that persuades the linker to do the "right thing" ?

7) there is no possibility of the linker following a 'bad chain', and thus linking in unused or otherwise redundant code ?

kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> Walter Bright wrote:
>>>
>>>> kris wrote:
>>>>
>>>>> What about (c) how templates are affected at each step ?
>>>>
>>>>
>>>>
>>>> It's the same algorithm - nothing special about templates.
>>>
>>>
>>> Is it possible, do you think, to be just a little more forthcoming on this?
>>>
>>> 1) when you batch-compile code with multiple references to a template, there is just one instance generated.
>>
>>
>> Yes.
>>
>>> 2) when you compile the same code modules individually, there are presumably multiple template instances generated?
>>
>>
>> Yes.
>>
>>> 3) how does the linker resolve the multiple template instances to just one?
>>
>>
>> The template instantiations are put into COMDAT sections, and the linker discards redundant ones.
> 
> Thank you;
> 
> 4) all symbols required to represent typeinfo and templates are now duplicated in each object file ?

My guess is separate compilation generates all TypeInfo and templates used by that module into the module's object file.  Which I believe is a "yes."

> 5) The linker does not have to search beyond the current object file for instances of #4 (as suggested by larsivi) ?

Correct.

> 6) the result is a library with many more duplicate symbols than before, but arranged in such a manner that persuades the linker to do the "right thing" ?

Yes.

> 7) there is no possibility of the linker following a 'bad chain', and thus linking in unused or otherwise redundant code ?

It certainly seems that way.  We get larger object files and libraries in exchange for smaller executables.  If any of the above is wrong, someone please correct me.


Sean

Sean Kelly wrote:
> kris wrote:
>> 6) the result is a library with many more duplicate symbols than before, but arranged in such a manner that persuades the linker to do the "right thing" ?
> 
> Yes.
> 
>> 7) there is no possibility of the linker following a 'bad chain', and thus linking in unused or otherwise redundant code ?
> 
> It certainly seems that way.  We get larger object files and libraries in exchange for smaller executables.  If any of the above is wrong, someone please correct me.

That agrees with my experience, although I'm not sure about the "smaller executables" part.  I think the reason why we sometimes get larger executables is more incidental than deliberate - so it doesn't always work out that way.  But if we opt for larger object files, then yes, we *always* get the smallest executable size as a result.

A nice thing to add to DMD for all this would be to emit "fat .obj files" when -c is supplied, no matter how many .d files are passed on the command line.  That way, the optimizations Walter has added (non-duplication of templates and typeinfo) will still become useful for direct-to-link situations (w/o -c).

-- 
- EricAnderton at yahoo