September 14, 2012
monarch_dodra:

>> int *p = [5].ptr;
>>
>> -Steve

But see this benchmark:


void main() {
    auto pointers = new int*[1_000_000];
    foreach (int i, ref p; pointers)
        p = [i].ptr;
    foreach (i; 0U .. 4_000_000_000U) {}
}


On my 32 bit system its RAM commit is about 23 MB. The pointers array takes about 4 MB. This means each "int" takes about 19 bytes of heap RAM instead of 4. Each int allocates some data (capacity) to extend the array.

Bye,
bearophile
September 14, 2012
On Fri, 14 Sep 2012 16:27:55 +0200, monarch_dodra <monarchdodra@gmail.com> wrote:

> On Friday, 14 September 2012 at 11:17:55 UTC, Jacob Carlborg wrote:
>> On 2012-09-14 12:52, monarch_dodra wrote:
>>
>>>> int x = void;
>>>>
>>>> http://dpaste.dzfl.pl/24c1baa9
>>>
>>> Hum, but that is a stack allocated variable.
>>
>> Perhaps using GC.malloc?
>
> Hum, apparently, there is a second (default aka-hidden) argument that is a bitmask applied to the allocated memory. So not much gain there.
>
> I'm allocating an array of 500_000 ulongs, and afterwards, I'm initializing them all "by hand", making the default allocation useless.
>
> I'm not going to lose any sleep over this, but there is no way in D to get (garbage collected) un-initialized memory/allocations?

What's wrong with GC.malloc? The bitmask is there to... well, many things.
Pass it BlkAttr.NO_SCAN to ensure memory is not initialized. I think that's
all what's needed.

-- 
Simen
September 14, 2012
On Friday, 14 September 2012 at 09:20:03 UTC, monarch_dodra wrote:
> This is going to be quick: Is it possible to allocate and initialize an int in the same line?
>
> int* p = new int(5);
>
> I haven't found a way to 1 liner it. Is it possible?
> Do I have to two liner it?
>
> int* p = new int();
> *p = 5;
>
> Thanks.

Firstly I thought this thread is purely about syntax. However, after rereading I think it is about problem of allocation on GC heap without default initialization. If I understood it right, possible solution is:

struct S
{
   ulong[500_000] array = void;
   void load(ulong value)
   {
      foreach (i, ref ulong v; array)
      {
         array[i] = value;
      }
   }
}

void main()
{
   // int* p = new int, x = ((*p=5) == 5) ? null : null;
   // assert(*p == 5);
   auto s = new S;
   s.load(5);
}
September 14, 2012
monarch_dodra:

> I'm allocating an array of 500_000 ulongs, and afterwards, I'm initializing them all "by hand", making the default allocation useless.

In std.array there are two functions to avoid a double initialization, mostly to be used for nonreference data.

Bye,
bearophile
September 14, 2012
On Friday, 14 September 2012 at 18:14:54 UTC, bearophile wrote:
> monarch_dodra:
>
>> I'm allocating an array of 500_000 ulongs, and afterwards, I'm initializing them all "by hand", making the default allocation useless.
>
> In std.array there are two functions to avoid a double initialization, mostly to be used for nonreference data.
>
> Bye,
> bearophile

http://dlang.org/phobos/std_array.html#uninitializedArray

and

http://dlang.org/phobos/std_array.html#minimallyInitializedArray
September 14, 2012
On Friday, 14 September 2012 at 14:27:43 UTC, monarch_dodra wrote:
> On Friday, 14 September 2012 at 11:17:55 UTC, Jacob Carlborg wrote:
>>
>> Perhaps using GC.malloc?
>
> Hum, apparently, there is a second (default aka-hidden) argument that is a bitmask applied to the allocated memory. So not much gain there.
>
> I'm allocating an array of 500_000 ulongs, and afterwards, I'm initializing them all "by hand", making the default allocation useless.
>
> I'm not going to lose any sleep over this, but there is no way in D to get (garbage collected) un-initialized memory/allocations?

Never mind, I misread the doc. The bitmask is not memcopied, it is actually just a mask of options, so GC works perfectly.

Anybody know what the attribute "FINALIZE" (Finalize the data in this block on collect) means?

On Friday, 14 September 2012 at 18:14:54 UTC, bearophile wrote:
> monarch_dodra:
>
>> I'm allocating an array of 500_000 ulongs, and afterwards, I'm initializing them all "by hand", making the default allocation useless.
>
> In std.array there are two functions to avoid a double initialization, mostly to be used for nonreference data.
>
> Bye,
> bearophile
I was looking for those actually, but I was looking in std.algorithm...

Thanks
September 14, 2012
On Fri, 14 Sep 2012 13:03:37 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> monarch_dodra:
>
>>> int *p = [5].ptr;
>>>
>>> -Steve
>
> But see this benchmark:
>
>
> void main() {
>      auto pointers = new int*[1_000_000];
>      foreach (int i, ref p; pointers)
>          p = [i].ptr;
>      foreach (i; 0U .. 4_000_000_000U) {}
> }
>
>
> On my 32 bit system its RAM commit is about 23 MB. The pointers array takes about 4 MB. This means each "int" takes about 19 bytes of heap RAM instead of 4. Each int allocates some data (capacity) to extend the array.

That has nothing to do with using array literals -- it has to do with the fact that the minimum heap block is 16-bytes (or 4 ints wide).  Extra 3 bytes is probably for overhead and static data.

If instead of p = [i].ptr; you did p = new int; *p = i;

You would get the same exact behavior.

No way around this, unless you want to do custom allocators.

-Steve
September 14, 2012
On Fri, 14 Sep 2012 15:23:40 -0400, monarch_dodra <monarchdodra@gmail.com> wrote:

> Anybody know what the attribute "FINALIZE" (Finalize the data in this block on collect) means?

Don't use it.

It specifies that the block is a D class instance, and so has a vtable with a finalizer referenced therein.

Obviously an int does not have that.

-Steve
September 14, 2012
Steven Schveighoffer:

> it has to do with the fact that the minimum heap block is 16-bytes
> (or 4 ints wide).  Extra 3 bytes is probably for overhead and static data.
>
> If instead of p = [i].ptr; you did p = new int; *p = i;
>
> You would get the same exact behavior.
>
> No way around this, unless you want to do custom allocators.

Right, maybe you told me the same thing lot of time ago. Thank you for saying such things again. 16 bytes are a lot, so there's not a lot of point in creating very small trees nodes :-)

Bye,
bearophile
1 2
Next ›   Last »