Am 08.02.2012, 04:40 Uhr, schrieb Jose Armando Garcia :
Special? What do you mean by special? Most OS use Virtual Memory so
sure they can say here is a page and yet not have that page backed by
physical memory. To my knowledge, they can only do this if the
allocated memory points to an unmapped
Am 07.02.2012, 22:15 Uhr, schrieb Iain Buclaw :
o zero out a memory block <-- !!!
What about these functions?
import std.array;
byte[][ALLOCS] a, b;
writeln("** uninitializedArray!(ubyte[])(1024*1024)");
foreach(i; 0 .. ALLOCS) b[i] = uninitializedArray!(ubyte[])(1024 * 102
On Tue, Feb 7, 2012 at 5:39 PM, Marco Leise wrote:
> Hi, this is me again with some "size matters" topic. This time, it's not
> the executable size, no! Instead I want to discuss a runtime memory
> footprint and speed issue that affects everyone, and how to improve the
> situation dramatically.
>
F i L wrote:
Only, if calloc is an all-around better allocation method than
malloc, why is malloc even used?
Note-to-self: google before asking stupid questions...
Marco Leise wrote:
> I'm not aware of any caveats, are there any?
The tests only cover a very small fraction of an unknown data
structure: the allocation phase.
Of course one can want to make a bad design running faster. Especially
if one need to allocate 0.5 TB main memory and can allocate th
Artur Skawina wrote:
That won't help - the compiler will defeat the optimization by
"initializing" the area...
I see.
Timon Gehr wrote:
The solution with the best performance and least memory
requirements obviously must be the default.
No argument here. Only, if calloc is an all-around bet
On 02/08/12 00:01, F i L wrote:
> Can't you just write a custom allocator using calloc for performance critical
> structures (http://dlang.org/memory.html#newdelete), or do what Iain said.
That won't help - the compiler will defeat the optimization by "initializing"
the area...
artur
On 02/08/2012 12:01 AM, F i L wrote:
Can't you just write a custom allocator using calloc for performance
critical structures (http://dlang.org/memory.html#newdelete), or do what
Iain said.
The solution with the best performance and least memory requirements
obviously must be the default.
Can't you just write a custom allocator using calloc for
performance critical structures
(http://dlang.org/memory.html#newdelete), or do what Iain said.
On 7 February 2012 19:39, Marco Leise wrote:
> Hi, this is me again with some "size matters" topic. This time, it's not
> the executable size, no! Instead I want to discuss a runtime memory
> footprint and speed issue that affects everyone, and how to improve the
> situation dramatically.
>
> In D
On 07/02/2012 2:11 PM, Nick Sabalausky wrote:
Is void initialization not good enough?
IIRC it's something like:
ubyte[] buf = void;
This example would be uninitializedArray!(ubyte[])(1024 * 1024).
I would guess that it gives significantly better performance. There's
also minimallyInitiali
Is void initialization not good enough?
IIRC it's something like:
ubyte[] buf = void;
Hi, this is me again with some "size matters" topic. This time, it's not
the executable size, no! Instead I want to discuss a runtime memory
footprint and speed issue that affects everyone, and how to improve the
situation dramatically.
In D we allocate memory through the GC, that is initialized
13 matches
Mail list logo
