Goodbye, garbage collector!

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Wed Sep 28 03:30:16 PDT 2011


I'm asking for std.allocator to be used in the language to be able to
use graphics card memory when doing image processing.
I would like to create allocators for allocating graphics card memory.
Perhaps even texture memory.
This would allow one to directly operate on pixels on the graphics
card and draw those pixels without ever copying them, which would lead
to incredible performance boost, when dealing with giant pixel
buffers, that get modified programmatically.
I would then use that graphics memory allocator with built-in arrays
and send those arrays over to some image processing algorithms.
Having such awesome integration with graphics hardware will lure lots
of graphics programmers over to D.
The back-end for that allocator will probably be OpenCL, as I see it.

On Wed, Sep 28, 2011 at 2:18 PM, Gor Gyolchanyan
<gor.f.gyolchanyan at gmail.com> wrote:
> I assume when the allocators come along, the flexibility of those
> constructs will increase, no?
> Also, wouldn't it be cleaner to allow reuse of the incredibly
> convenient syntax of built-in arrays and enable one to replace it's
> allocators?
> Some properties, maybe? Something like this:
>
> -----
> int[] array;
> assert(is(array.allocator == DynamicAllocator)); // This equals to
> GCAllocator().dynamicAllocator().
> array.allocator = RegionAllocator.dynamicAllocator().
> -----
>
> And the functions of the allcoators, that create arrays, using that
> allcoator would write the above statements.
> How about this? And how much the performance would drop if we
> introduced DynamicAllocators to do all the allocations?
> Is there any other solution you could suggest, that would allow using
> built-in array syntax?
> What about stack frames, that get moved to heap?
>
> On Wed, Sep 28, 2011 at 1:57 PM, Bernard Helyer <b.helyer at gmail.com> wrote:
>> Using Array!T in place of T[] would work, if you don't mind malloc/free.
>> Also, overriding new and delete (and delete itself) are going -- relying
>> on them is not advisable. Use emplace and clear, instead.
>>
>


More information about the Digitalmars-d mailing list