On Sunday, 9 February 2014 at 12:36:38 UTC, Dicebot wrote:
> On Sunday, 9 February 2014 at 04:14:05 UTC, Marco Leise wrote:
>> It depends on what syntax you expect. I solved it this way:
>>
>> void fun(alias length)(void* sneaky = alloca(length));
>>
>> void foo()
>> {
>>    size_t myLength = 42;
>>    fun!myLength();
>> }
>
> Huge template bloat in current frontend state - new instance of `fun` for every single new function it is used in.

The implementation of `fun` can just forward `sneaky` onto another function. Cue some simple inlining and there is no bloat (at runtime, anyhow).

On Sunday, 9 February 2014 at 12:57:32 UTC, Jakob Ovrum wrote:
> The implementation of `fun` can just forward `sneaky` onto another function. Cue some simple inlining and there is no bloat (at runtime, anyhow).

I am not speaking about what "sufficiently clever compiler" can do but what current frontend does. New aliased identifier == new instance. Always.

On Sunday, 9 February 2014 at 13:08:45 UTC, Dicebot wrote:
> On Sunday, 9 February 2014 at 12:57:32 UTC, Jakob Ovrum wrote:
>> The implementation of `fun` can just forward `sneaky` onto another function. Cue some simple inlining and there is no bloat (at runtime, anyhow).
>
> I am not speaking about what "sufficiently clever compiler" can do but what current frontend does. New aliased identifier == new instance. Always.

Yes, but a new template instance is not necessarily a problem at runtime or for the executable size. The contents of the template instance is all that matters. When the content is a tiny inlinable function, there is no bloat.

On Sunday, 9 February 2014 at 13:11:57 UTC, Jakob Ovrum wrote:
> Yes, but a new template instance is not necessarily a problem at runtime or for the executable size. The contents of the template instance is all that matters. When the content is a tiny inlinable function, there is no bloat.

I have investiagted relevant parts of DMD for months. It simply does not work that way and changing it would require huge frontend refactoring. Inlining does not affect bloat in DMD at all. Every instance that is ever mentioned in code will always make its way to the target binary. You can trivially check it.

On Sunday, 9 February 2014 at 13:14:00 UTC, Dicebot wrote:
> On Sunday, 9 February 2014 at 13:11:57 UTC, Jakob Ovrum wrote:
>> Yes, but a new template instance is not necessarily a problem at runtime or for the executable size. The contents of the template instance is all that matters. When the content is a tiny inlinable function, there is no bloat.
>
> I have investiagted relevant parts of DMD for months. It simply does not work that way and changing it would require huge frontend refactoring. Inlining does not affect bloat in DMD at all. Every instance that is ever mentioned in code will always make its way to the target binary. You can trivially check it.

It is the linker's job to purge unused code.

On Sunday, 9 February 2014 at 13:19:40 UTC, Jakob Ovrum wrote:
>> I have investiagted relevant parts of DMD for months. It simply does not work that way and changing it would require huge frontend refactoring. Inlining does not affect bloat in DMD at all. Every instance that is ever mentioned in code will always make its way to the target binary. You can trivially check it.
>
> It is the linker's job to purge unused code.

Please show me the one who is capable of doing it. ld's --gc-sections currently breaks binaries and it is the only one I am aware about.

On 2/9/2014 4:30 AM, Jacob Carlborg wrote:
> * Could we put this in a more general package, like
> std.memory.buffer.scopebuffer. Then the upcoming std.allocator could be placed
> in std.memory.allocator

In druntime there are many examples of deeply nested packages. Personally, I never can remember which one a particular module is in and are always using directory searches to find them. I much prefer a flatter structure.

Besides, I don't see that buffers are a subset of memory allocation strategies, I think they're orthogonal.


> * Do we have any uses for this in druntime? Perhaps move core.memory to
> core.memory.gc and put this module in core.memory.buffer.scopebuffer.

Of course, the distinction between druntime and phobos is a bit arbitrary, but given that lots of buffer types are coming, I don't see much value in having some buffer types in druntime and some in phobos.

07-Feb-2014 12:24, Walter Bright пишет:
> https://github.com/D-Programming-Language/phobos/pull/1911
>
> This adds a package std.buffer, and the first entry in that package,
> std.buffer.scopebuffer.
>
> ScopeBuffer is an OutputRange that sits on the stack, and overflows to
> malloc/free. It's designed to help in eliminating gc allocation by lower
> level functions that return buffers, such as std.path.buildPath(). With
> some judicious user tuning of the initial stack size, it can virtually
> eliminate storage allocation.
>
> Using it is @system, but the user of ScopeBuffer can be @trusted.
>
> An output range like this is a precursor to eliminating the excessive gc
> use by functions such as buildPath().

Some food for thought:

1. I guess there is a distinctive quality to a buffer (i.e. it's not just any output range). The current interface looks quite arbitrary - is 'pop' required for any buffer? A trait like isBuffer is in order, to allow user code to target any buffers including non-Phobos ones.

2. May need buffer.package.d to import all common buffers (there is only one now, but with time...).


-- 
Dmitry Olshansky

On 2/9/2014 12:43 PM, Dmitry Olshansky wrote:

> 1. I guess there is a distinctive quality to a buffer (i.e. it's not just any
> output range). The current interface looks quite arbitrary - is 'pop' required
> for any buffer?

No, pop isn't required.

> A trait like isBuffer is in order, to allow user code to target
> any buffers including non-Phobos ones.

I don't understand the point of this suggestion.

> 2. May need buffer.package.d to import all common buffers (there is only one
> now, but with time...).

I do not like the idea of "kitchen sink" importing. The package.d thing was designed so that we can split up the existing kitchen sink modules without breaking user code.

On 2/9/2014 5:48 AM, Dicebot wrote:
> On Sunday, 9 February 2014 at 13:19:40 UTC, Jakob Ovrum wrote:
>>> I have investiagted relevant parts of DMD for months. It simply does not work
>>> that way and changing it would require huge frontend refactoring. Inlining
>>> does not affect bloat in DMD at all. Every instance that is ever mentioned in
>>> code will always make its way to the target binary. You can trivially check it.
>>
>> It is the linker's job to purge unused code.
>
> Please show me the one who is capable of doing it. ld's --gc-sections currently
> breaks binaries and it is the only one I am aware about.

You're right. Unfortunately, D has to use existing linkers. That means we cannot build the compiler to require a possible, desirable, but non-existent linking technology.