On 20/10/2013 21:39, Tove wrote:
>
> ref E stalloc(E)(ref E mem = *(cast(E*)alloca(E.sizeof)))
> {
>    return mem;
> }

Another trick is to use a template alias parameter for array length:

T[] stackArray(T, alias N)(void* m = alloca(T.sizeof * N))
{
    return (cast(T*)m)[0 .. N];
}

void main(string[] args)
{
    auto n = args.length;
    int[] arr = stackArray!(int, n)();
}

Note: The built-in length property couldn't be aliased when I tested this, hence 'n'. Reference:

http://forum.dlang.org/post/aepqtotvkjyausrlsmad@forum.dlang.org

On 20/10/2013 20:23, bearophile wrote:
>  From what I've seen escape analysis is not bringing Java close to D
> performance when you use 3D vectors implemented as small class
> instances. We need something that guarantees stack allocation if there's
> enough space on the stack.

If my recollection and understanding are correct, that's not due to a limitation in the algorithm itself of Java's escape analysis, but because Java arrays are allocated using a native call (even within the Java bytecode layer that is), and the escape analysis does not see beyond any native call. Even if it originates from a Java operation with well-known semantics (with regards to escape analysis).
Thefore it can't ellide the allocations... :/

-- 
Bruno Medeiros - Software Engineer

Am 22.10.2013 14:26, schrieb Bruno Medeiros:
> On 20/10/2013 20:23, bearophile wrote:
>>  From what I've seen escape analysis is not bringing Java close to D
>> performance when you use 3D vectors implemented as small class
>> instances. We need something that guarantees stack allocation if there's
>> enough space on the stack.
>
> If my recollection and understanding are correct, that's not due to a
> limitation in the algorithm itself of Java's escape analysis, but
> because Java arrays are allocated using a native call (even within the
> Java bytecode layer that is), and the escape analysis does not see
> beyond any native call. Even if it originates from a Java operation with
> well-known semantics (with regards to escape analysis).
> Thefore it can't ellide the allocations... :/
>

Just thinking out loud, I would say it is JVM specific how much the implementors have improved escape analysis.

--
Paulo

On Tuesday, 22 October 2013 at 15:07:47 UTC, Paulo Pinto wrote:
> Just thinking out loud, I would say it is JVM specific how much the implementors have improved escape analysis.
>

Even better, some does it even when escape analysis isn't proven, just noticed at runtime. If it turns out the JVM is wrong, the object is moved on head at the escape point.

Am 22.10.2013 19:51, schrieb deadalnix:
> On Tuesday, 22 October 2013 at 15:07:47 UTC, Paulo Pinto wrote:
>> Just thinking out loud, I would say it is JVM specific how much the
>> implementors have improved escape analysis.
>>
>
> Even better, some does it even when escape analysis isn't proven, just
> noticed at runtime. If it turns out the JVM is wrong, the object is
> moved on head at the escape point.

Yep, I must confess I keep jumping between both sides of the fence about the whole JIT vs AOT compilation, depending on the use case and
deployment scenario.

For example, as language geek it was quite interesting to discover how
OS/400 has a kernel JIT with a bytecode based userspace. Or that there
were Native Oberon ports that used JIT on module load for the whole OS,
instead of AOT. Only the boot loader, some critical drivers and the kernel module were AOT.

--
Paulo

On 10/21/13 15:04, Manu wrote:
> On 21 October 2013 21:24, Denis Shelomovskij
> <verylonglogin.reg@gmail.com <mailto:verylonglogin.reg@gmail.com>> wrote:
>
>     21.10.2013 14:30, Manu пишет:
>
>         System interface functions that pass zero-terminated strings
>         through to
>         the OS are the primary offender, needless garbage, those should
>         be on
>         the stack.
>
>         I like to use alloca too where it's appropriate. I'd definitely
>         like if
>         D had a variable-sized static array syntax for pretty-ing alloca.
>         I thought about something similar using alloca via a mixin
>         template, but
>         that feels really hackey!
>
>
>     No hacks needed. See `unstd.c.string` module from previous post:
>     http://forum.dlang.org/thread/__lqdktyndevxfcewgthcj@forum.__dlang.org?page=2#post-l42evp:__241ok7:241:40digitalmars.com
>     <http://forum.dlang.org/thread/lqdktyndevxfcewgthcj@forum.dlang.org?page=2#post-l42evp:241ok7:241:40digitalmars.com>
>
>
> Super awesome! Phobos devs should be encouraged to use these in
> non-recursive functions (particularly OS pass-through's).

Careful! Alloca doesn't get cleaned up when used in loops!

foreach(t; 0..1000) { int[t] stack_overflow; }

On Sunday, 20 October 2013 at 16:33:35 UTC, Walter Bright wrote:
> On 10/20/2013 7:25 AM, bearophile wrote:
>> More discussions about variable-sized stack-allocated arrays in C++, it seems
>> there is no yet a consensus:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
>>
>> I'd like variable-sized stack-allocated arrays in D.
>
> They're far more trouble than they're worth.
>
> Just use:
>
>     auto a = new T[n];
>
> Stack allocated arrays are far more trouble than they're worth. But what about efficiency? Here's what I often do something along the lines of:
>
>     T[10] tmp;
>     T[] a;
>     if (n <= 10)
> 	a = tmp[0..n];
>     else
> 	a = new T[n];
>     scope (exit) if (a != tmp) delete a;
>
> The size of the static array is selected so the dynamic allocation is almost never necessary.

Another idea would be to use something like this:
http://dpaste.dzfl.pl/8613c9be
It has a syntax similar to T[n] and is likely more efficient because the memory is freed when it is no longer needed. :)

Am 23.10.2013 15:59, schrieb Namespace:
> On Sunday, 20 October 2013 at 16:33:35 UTC, Walter Bright wrote:
>> On 10/20/2013 7:25 AM, bearophile wrote:
>>> More discussions about variable-sized stack-allocated arrays
>>> in C++, it seems
>>> there is no yet a consensus:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
>>>
>>> I'd like variable-sized stack-allocated arrays in D.
>>
>> They're far more trouble than they're worth.
>>
>> Just use:
>>
>>     auto a = new T[n];
>>
>> Stack allocated arrays are far more trouble than they're worth.
>> But what about efficiency? Here's what I often do something
>> along the lines of:
>>
>>     T[10] tmp;
>>     T[] a;
>>     if (n <= 10)
>> 	a = tmp[0..n];
>>     else
>> 	a = new T[n];
>>     scope (exit) if (a != tmp) delete a;
>>
>> The size of the static array is selected so the dynamic
>> allocation is almost never necessary.
>
> Another idea would be to use something like this:
> http://dpaste.dzfl.pl/8613c9be
> It has a syntax similar to T[n] and is likely more efficient
> because the memory is freed when it is no longer needed. :)
>

but it would be still nice to change the 4096 size by template parameter maybe defaulted to 4096 :)

On Wednesday, 23 October 2013 at 14:35:12 UTC, dennis luehring wrote:
> Am 23.10.2013 15:59, schrieb Namespace:
>> On Sunday, 20 October 2013 at 16:33:35 UTC, Walter Bright wrote:
>>> On 10/20/2013 7:25 AM, bearophile wrote:
>>>> More discussions about variable-sized stack-allocated arrays
>>>> in C++, it seems
>>>> there is no yet a consensus:
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
>>>>
>>>> I'd like variable-sized stack-allocated arrays in D.
>>>
>>> They're far more trouble than they're worth.
>>>
>>> Just use:
>>>
>>>    auto a = new T[n];
>>>
>>> Stack allocated arrays are far more trouble than they're worth.
>>> But what about efficiency? Here's what I often do something
>>> along the lines of:
>>>
>>>    T[10] tmp;
>>>    T[] a;
>>>    if (n <= 10)
>>> 	a = tmp[0..n];
>>>    else
>>> 	a = new T[n];
>>>    scope (exit) if (a != tmp) delete a;
>>>
>>> The size of the static array is selected so the dynamic
>>> allocation is almost never necessary.
>>
>> Another idea would be to use something like this:
>> http://dpaste.dzfl.pl/8613c9be
>> It has a syntax similar to T[n] and is likely more efficient
>> because the memory is freed when it is no longer needed. :)
>>
>
> but it would be still nice to change the 4096 size by template parameter maybe defaulted to 4096 :)

That is true. ;) And can be easily done. :)

Am 23.10.2013 16:41, schrieb Namespace:
> On Wednesday, 23 October 2013 at 14:35:12 UTC, dennis luehring
> wrote:
>> Am 23.10.2013 15:59, schrieb Namespace:
>>> On Sunday, 20 October 2013 at 16:33:35 UTC, Walter Bright
>>> wrote:
>>>> On 10/20/2013 7:25 AM, bearophile wrote:
>>>>> More discussions about variable-sized stack-allocated arrays
>>>>> in C++, it seems
>>>>> there is no yet a consensus:
>>>>>
>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
>>>>>
>>>>> I'd like variable-sized stack-allocated arrays in D.
>>>>
>>>> They're far more trouble than they're worth.
>>>>
>>>> Just use:
>>>>
>>>>    auto a = new T[n];
>>>>
>>>> Stack allocated arrays are far more trouble than they're
>>>> worth.
>>>> But what about efficiency? Here's what I often do something
>>>> along the lines of:
>>>>
>>>>    T[10] tmp;
>>>>    T[] a;
>>>>    if (n <= 10)
>>>> 	a = tmp[0..n];
>>>>    else
>>>> 	a = new T[n];
>>>>    scope (exit) if (a != tmp) delete a;
>>>>
>>>> The size of the static array is selected so the dynamic
>>>> allocation is almost never necessary.
>>>
>>> Another idea would be to use something like this:
>>> http://dpaste.dzfl.pl/8613c9be
>>> It has a syntax similar to T[n] and is likely more efficient
>>> because the memory is freed when it is no longer needed. :)
>>>
>>
>> but it would be still nice to change the 4096 size by template
>> parameter maybe defaulted to 4096 :)
>
> That is true. ;) And can be easily done. :)
>

can't you remove the if(this.ptr is null) return; checks everywhere - how should that happen - without exception at creation time