Goodbye, garbage collector!

[Dmitry Olshansky]

On 28.09.2011 14:30, Gor Gyolchanyan wrote:
> 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

All good and well, but you certainly can't operate on pixels _directly_, 
only through API calls, OpenCL kernels and other GPU specific stuff. 
Otherwise you just copy them to RAM modify as you see fit and copy back.

> 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.

Then image processing algorithms should use OpenCL as well, and the more 
I look on this idea (awesome btw) the more I think it should be just 
special GPU vector type with its own framework of utility functions.

> 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.
>>>
>>


-- 
Dmitry Olshansky