You can see of this as a small DEP :-)

Small variable-length arrays allocated on the stack can be somewhat useful in D. They avoid most usages of alloca() and are a bit safer than alloca() because no pointer casting is needed.

alloca() gives some performance improvement compared to normal dynamic arrays if the array is small and the function (here bar()) is called many times (I have experimentally seen this in the Levenshtein distance function, that needs to allocate a temporary buffer. If the length of the two input strings is small I use a fixed-sized array as buffer, this improves performance some in code that needs to compute this distance over many small strings. I think a variable-length array is a bit better here. In this situation often Tango adopts the strategy of adding an extra function argument that allows to give a preallocated buffer to a function).

The syntax that can be used for such arrays is nothing strange, it's the same as fixed-sized arrays, but the length is a run-time variable:

void foo(int[] b) {} // OK
// void foo(int[100] b) {} // Wrong

void bar(int n) {
  int[n] a; // stack-allocated, variable-size
  foo(a);
}

When you give one of such variable-length arrays to another function like foo(), it must always become a dynamic array, because the length is not generally unknown at compile time.

An alternative syntax that I don't like (too much long, and it doesn't allow to add =void):

void bar(int n) {
  scope int[] a = new int[n]; // stack-allocated
  foo(a);
}

The advantage of this scope int[] a =... syntax is that it's quite easy to see that it's a stack allocation, but I think this is not important.

Bye,
bearophile

bearophile wrote:
> void bar(int n) {
>   scope int[] a = new int[n]; // stack-allocated
>   foo(a);
> }

Why are you making such proposals, when one of the core developers even thought about removing normal "scope"? It's almost 100% guaranteed that nobody will listen.

I personally find it a good idea to find new ways to reduce producing memory garbage. The D GC is slow and bad, so you'd better avoid it.

Let's make this claim: it is impossible to write high performance applications (that need to make use of dynamic memory allocation) in D without resorting to "unsafe" techniques. That would include allocating memory on the stack, or manually freeing memory.

Maybe D should have focused more on safe and efficient memory managment concepts, like they can be found in languages like Cyclone (though I don't know how useful/feasible this is, but it sounded promising).

grauzone wrote:
> bearophile wrote:
>> void bar(int n) {
>>   scope int[] a = new int[n]; // stack-allocated
>>   foo(a);
>> }
> 
> Why are you making such proposals, when one of the core developers even thought about removing normal "scope"? It's almost 100% guaranteed that nobody will listen.
> 
> I personally find it a good idea to find new ways to reduce producing memory garbage. The D GC is slow and bad, so you'd better avoid it.
> 
> Let's make this claim: it is impossible to write high performance applications (that need to make use of dynamic memory allocation) in D without resorting to "unsafe" techniques. That would include allocating memory on the stack, or manually freeing memory.

I write high-performance code in D without resorting to unsafe techniques. Much of my code allocates arrays only in the beginning and uses them throughout.


Andrei

Andrei Alexandrescu wrote:
> grauzone wrote:
>> bearophile wrote:
>>> void bar(int n) {
>>>   scope int[] a = new int[n]; // stack-allocated
>>>   foo(a);
>>> }
>>
>> Why are you making such proposals, when one of the core developers even thought about removing normal "scope"? It's almost 100% guaranteed that nobody will listen.
>>
>> I personally find it a good idea to find new ways to reduce producing memory garbage. The D GC is slow and bad, so you'd better avoid it.
>>
>> Let's make this claim: it is impossible to write high performance applications (that need to make use of dynamic memory allocation) in D without resorting to "unsafe" techniques. That would include allocating memory on the stack, or manually freeing memory.
> 
> I write high-performance code in D without resorting to unsafe techniques. Much of my code allocates arrays only in the beginning and uses them throughout.

I intended to exclude this case with applications "that need to make use of dynamic memory allocation". But I guess this doesn't apply to programs that only allocate on initialization.

So, how about programs that allocate/release memory while doing computations?

> 
> Andrei

grauzone wrote:
> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>> bearophile wrote:
>>>> void bar(int n) {
>>>>   scope int[] a = new int[n]; // stack-allocated
>>>>   foo(a);
>>>> }
>>>
>>> Why are you making such proposals, when one of the core developers even thought about removing normal "scope"? It's almost 100% guaranteed that nobody will listen.
>>>
>>> I personally find it a good idea to find new ways to reduce producing memory garbage. The D GC is slow and bad, so you'd better avoid it.
>>>
>>> Let's make this claim: it is impossible to write high performance applications (that need to make use of dynamic memory allocation) in D without resorting to "unsafe" techniques. That would include allocating memory on the stack, or manually freeing memory.
>>
>> I write high-performance code in D without resorting to unsafe techniques. Much of my code allocates arrays only in the beginning and uses them throughout.
> 
> I intended to exclude this case with applications "that need to make use of dynamic memory allocation". But I guess this doesn't apply to programs that only allocate on initialization.
> 
> So, how about programs that allocate/release memory while doing computations?

"Oil is found in the minds of men."

Andrei

grauzone:
> Why are you making such proposals, when one of the core developers even thought about removing normal "scope"?

I have a nice implementation of Barnes-Hut algorithm translated from Java. Its running time goes from 18.1 seconds to 7.6 s adding "scope" where some classes are initialized (those classes are 3D vectors, that can also become structs).

If scope classes are removed, then it may be necessary to add struct inheritance to D2, because in several situations objects can't be used (and by the way, the very latest Java HotSpot needs about 10.9 s to run the same code, despite it performs Escape Analysis, probably because such Analysis is not as good as my manual scope annotations). On request I can show all the code discussed here.

Bye,
bearophile

Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> grauzone wrote:
>>>> bearophile wrote:
>>>>> void bar(int n) {
>>>>>   scope int[] a = new int[n]; // stack-allocated
>>>>>   foo(a);
>>>>> }
>>>>
>>>> Why are you making such proposals, when one of the core developers even thought about removing normal "scope"? It's almost 100% guaranteed that nobody will listen.
>>>>
>>>> I personally find it a good idea to find new ways to reduce producing memory garbage. The D GC is slow and bad, so you'd better avoid it.
>>>>
>>>> Let's make this claim: it is impossible to write high performance applications (that need to make use of dynamic memory allocation) in D without resorting to "unsafe" techniques. That would include allocating memory on the stack, or manually freeing memory.
>>>
>>> I write high-performance code in D without resorting to unsafe techniques. Much of my code allocates arrays only in the beginning and uses them throughout.
>>
>> I intended to exclude this case with applications "that need to make use of dynamic memory allocation". But I guess this doesn't apply to programs that only allocate on initialization.
>>
>> So, how about programs that allocate/release memory while doing computations?
> 
> "Oil is found in the minds of men."

Can you explain what this means in the context of the problem mentioned above?

> Andrei

Andrei Alexandrescu:

> "Oil is found in the minds of men."

I hope your book will put some good oil in my head :-)

Bye,
bearophile

grauzone:
> Why are you making such proposals, when one of the core developers even thought about removing normal "scope"?

And by the way, in the Python community one of the purposes of PEPs is to act as an archive of refused proposals, so people can avoid wasting brain energy over and over again about permanently refused ideas :-)
Sometimes it's worth doing well even wrong things :-)

Bye,
bearophile

grauzone wrote:
> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>> Andrei Alexandrescu wrote:
>>>> grauzone wrote:
>>>>> bearophile wrote:
>>>>>> void bar(int n) {
>>>>>>   scope int[] a = new int[n]; // stack-allocated
>>>>>>   foo(a);
>>>>>> }
>>>>>
>>>>> Why are you making such proposals, when one of the core developers even thought about removing normal "scope"? It's almost 100% guaranteed that nobody will listen.
>>>>>
>>>>> I personally find it a good idea to find new ways to reduce producing memory garbage. The D GC is slow and bad, so you'd better avoid it.
>>>>>
>>>>> Let's make this claim: it is impossible to write high performance applications (that need to make use of dynamic memory allocation) in D without resorting to "unsafe" techniques. That would include allocating memory on the stack, or manually freeing memory.
>>>>
>>>> I write high-performance code in D without resorting to unsafe techniques. Much of my code allocates arrays only in the beginning and uses them throughout.
>>>
>>> I intended to exclude this case with applications "that need to make use of dynamic memory allocation". But I guess this doesn't apply to programs that only allocate on initialization.
>>>
>>> So, how about programs that allocate/release memory while doing computations?
>>
>> "Oil is found in the minds of men."
> 
> Can you explain what this means in the context of the problem mentioned above?

It means that if you start with the goal of making high performance applications safe, you may achieve that. One guaranteed way to not get there is to start with a claim that it can't be done.

That being said, I like stack-allocated and I asked Walter for a long time to introduce them in the language. They have their problems though.


Andrei