On Monday, 15 July 2013 at 17:39:43 UTC, H. S. Teoh wrote:
On Mon, Jul 15, 2013 at 07:32:37PM +0200, monarch_dodra wrote:
On Monday, 15 July 2013 at 15:54:57 UTC, bearophile wrote:
>monarch_dodra:
>
>>>But that (of new arrays) is a bad design, it wastes too much
>>>memory, and I think it should
Namespace:
Ah, good to know. But anyway malloc allocates exact N elements,
without ugly overhead.
Would be really good if there was a way to avoid that the GC
takes over the memory.
That wasted space is what you pay to reduce memory fragmentation
with a not copying GC.
Bye,
bearophile
On Mon, Jul 15, 2013 at 09:53:32PM +0200, Namespace wrote:
> On Monday, 15 July 2013 at 18:29:12 UTC, Adam D. Ruppe wrote:
> >On Monday, 15 July 2013 at 18:16:45 UTC, Namespace wrote:
> >>writeln(arr.length, "::", arr.capacity);
> >
> >arr.capacity checks the GC block, and since you malloced it, th
On 07/15/2013 12:53 PM, Namespace wrote:
> But anyway malloc allocates exact N elements, without ugly overhead.
I doubt it. If its allocating from a bucket, then what actually gets
used is the size of that bucket.
Ali
On Monday, 15 July 2013 at 18:29:12 UTC, Adam D. Ruppe wrote:
On Monday, 15 July 2013 at 18:16:45 UTC, Namespace wrote:
writeln(arr.length, "::", arr.capacity);
arr.capacity checks the GC block, and since you malloced it,
there is no gc block for it to check. So it simply doesn't know
if the
On Monday, 15 July 2013 at 18:16:45 UTC, Namespace wrote:
writeln(arr.length, "::", arr.capacity);
arr.capacity checks the GC block, and since you malloced it,
there is no gc block for it to check. So it simply doesn't know
if there's any extra capacity there and reports 0 just to be safe.
No. *EVEN* with an "ugly malloc", you'll still over allocate
(see above).
int* ptr = cast(int*) malloc(513 * int.sizeof);
int[] arr = ptr[0 .. 513];
writeln(arr.length, "::", arr.capacity);
Output:
513::0
Where is the over allocation?
On Mon, Jul 15, 2013 at 07:32:37PM +0200, monarch_dodra wrote:
> On Monday, 15 July 2013 at 15:54:57 UTC, bearophile wrote:
> >monarch_dodra:
> >
> >>>But that (of new arrays) is a bad design, it wastes too much
> >>>memory, and I think it should be fixed. In Python this doesn't
> >>>overallocate:
On Monday, 15 July 2013 at 15:54:57 UTC, bearophile wrote:
monarch_dodra:
But that (of new arrays) is a bad design, it wastes too much
memory, and I think it should be fixed. In Python this
doesn't overallocate:
So what? The only thing you showed, is that
minimallyInitialized doesn't know h
monarch_dodra:
But that (of new arrays) is a bad design, it wastes too much
memory, and I think it should be fixed. In Python this doesn't
overallocate:
So what? The only thing you showed, is that
minimallyInitialized doesn't know how much it allocated. If you
allocate 513 elements with mal
On Monday, 15 July 2013 at 13:13:42 UTC, bearophile wrote:
Output:
512 1019
512 1019
512 0
But that (of new arrays) is a bad design, it wastes too much
memory, and I think it should be fixed. In Python this doesn't
overallocate:
So what? The only thing you showed, is that minimallyInitialize
Namespace:
Is it possible to prohibit that the slice is resized, to avoid
GC allocations?
For that I think you need to define a struct that disables the
append and uses an alias this. But then some of your array
function argument signatures need to change, because lot of D
code uses "raw" a
Another question:
I have this code:
void main() {
int* ptr = cast(int*) malloc(11 * int.sizeof);
int[] arr = ptr[0 .. 11];
assert(arr.ptr is ptr);
arr ~= 42;
assert(ptr !is arr.ptr);
}
Is it possible to prohibit that the slice is resized, to a
Namespace:
void main()
{
int[] arr1 = new int[512];
writeln(arr1.length, "::", arr1.capacity);
int[] arr2 = new int[](512);
writeln(arr2.length, "::", arr2.capacity);
}
Output:
512::1019
512::1019
import std.stdio, std.array;
void main() {
auto a1 = ne
On Monday, 15 July 2013 at 12:23:21 UTC, Adam D. Ruppe wrote:
On Monday, 15 July 2013 at 11:46:54 UTC, Namespace wrote:
int[] arr = new int[sizeOfItems];
Did you also try int[] arr = new int[](sizeOfItems)?
Example code:
void main()
{
int[] arr1 = new int[512];
writeln(a
On Monday, 15 July 2013 at 11:46:54 UTC, Namespace wrote:
int[] arr = new int[sizeOfItems];
Did you also try int[] arr = new int[](sizeOfItems)?
Is there no way (besides the ugly malloc or any wrappers) to
allocate _exactly_ N elements at runtime (no static array)?
I tried
int[] arr = new int[sizeOfItems];
but if sizeOfItems is e.g. 512, it allocates 1024.
So is there no way to allocate a fixed memory block without the
usage of
17 matches
Mail list logo