www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Goodbye, garbage collector!

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I have a question about switching to 100% manual memory management.
I know how it should be done with structs and classes: override the
new and delete.
But i don't know how to do it for arrays, associative arrays, stack
frames for delegates and all other instances of implicit memory
allocation.
Is there a way to completely override all memory allocations, so that
i can use the language to the fullest in performance-critical places?

Cheers,
Gor.
Sep 28 2011
next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
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.
Sep 28 2011
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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 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.
Sep 28 2011
prev sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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 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 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.
Sep 28 2011
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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 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 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
Sep 28 2011
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Something similar to GPU vector type, but more general.
Instead of GPU - any desired device, available ATM.
instead of vector - any data type, supported by OpenCL.
The whole point is to hide OpenCL under intuitive D-interface, so that
the GPU data and computation would be as close to CPU (D) computation
as possible.

On Wed, Sep 28, 2011 at 4:14 PM, Dmitry Olshansky <dmitry.olsh gmail.com> w=
rote:

 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 specia=


l

 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 gmail.com> =A0wrote:

 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 =3D=3D DynamicAllocator)); // This equals to
 GCAllocator().dynamicAllocator().
 array.allocator =3D 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 gmail.com>
 =A0wrote:

 Using Array!T in place of T[] would work, if you don't mind malloc/fre=








e.

 Also, overriding new and delete (and delete itself) are going -- relyi=








ng

 on them is not advisable. Use emplace and clear, instead.







 --
 Dmitry Olshansky
Sep 28 2011
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 28.09.2011, 14:14 Uhr, schrieb Dmitry Olshansky <dmitry.olsh gmail.com>:


 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.


You can always map the texture memory into client address space.
http://www.opengl.org/sdk/docs/man/xhtml/glMapBuffer.xml

This allows modifications via DMA. But you cannot use the texture while  
you have it mapped. And unmapping it *may* fail in certain situations. The  
allocator interface would have to allow for locking/mapping memory blocks  
and gracefully handle the case where unlocking/umapping fails.

-- Marco
Sep 28 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
This is so cool! Thanks! I'll look into it!

On Thu, Sep 29, 2011 at 7:18 AM, Marco Leise <Marco.Leise gmx.de> wrote:

 Am 28.09.2011, 14:14 Uhr, schrieb Dmitry Olshansky <dmitry.olsh gmail.com>:


 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.


 You can always map the texture memory into client address space.
 http://www.opengl.org/sdk/docs/man/xhtml/glMapBuffer.xml

 This allows modifications via DMA. But you cannot use the texture while you
 have it mapped. And unmapping it *may* fail in certain situations. The
 allocator interface would have to allow for locking/mapping memory blocks
 and gracefully handle the case where unlocking/umapping fails.

 -- Marco
Sep 29 2011
prev sibling parent reply Trass3r <un known.com> writes:
 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.


Have you ever used OpenCL?
Sep 28 2011
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Read news, specs, presentations about it.
Have a clear overall understanding of it.
Downloaded the API recently.
Went through examples.
Gonna try making hello world examples.

On Wed, Sep 28, 2011 at 4:27 PM, Trass3r <un known.com> wrote:

 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.


 Have you ever used OpenCL?
Sep 28 2011
parent reply Trass3r <un known.com> writes:
 Read news, specs, presentations about it.
 Have a clear overall understanding of it.
 Downloaded the API recently.
 Went through examples.


Well GPGPU only comes with big performance gains if you hand-tune the  
(kernel and API interaction) code.
Normally you even have to optimize it for specific GPUs to optimally use  
local memory etc.
or you will end up being not much faster than a proper multi-threaded CPU  
implementation in most cases.


 Gonna try making hello world examples.


If you want to use it with D:
https://bitbucket.org/trass3r/cl4d
Sep 28 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Cool! A ready OO-wrapper. Thanks.
I agree, the best-performance GPGPU code needs fine tuning (although
any kind of computation on giant arrays of floats is much faster on a
GPU, then on a multi-threaded CPU).
That's why i want my data structures and computation to be
fine-tunable in respect of hardware.
And, optionally, I'd want it to smoothly integrate with my main D
computation, from which the kernels are generated and processed.

On Wed, Sep 28, 2011 at 5:30 PM, Trass3r <un known.com> wrote:

 Read news, specs, presentations about it.
 Have a clear overall understanding of it.
 Downloaded the API recently.
 Went through examples.


 Well GPGPU only comes with big performance gains if you hand-tune the
 (kernel and API interaction) code.
 Normally you even have to optimize it for specific GPUs to optimally use
 local memory etc.
 or you will end up being not much faster than a proper multi-threaded CPU
 implementation in most cases.


 Gonna try making hello world examples.


 If you want to use it with D:
 https://bitbucket.org/trass3r/cl4d
Sep 28 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Gor Gyolchanyan Wrote:


 I have a question about switching to 100% manual memory management.
 I know how it should be done with structs and classes: override the
 new and delete.
 But i don't know how to do it for arrays, associative arrays, stack
 frames for delegates and all other instances of implicit memory
 allocation.
 Is there a way to completely override all memory allocations, so that
 i can use the language to the fullest in performance-critical places?
 
 Cheers,
 Gor.


allocation is done by druntime, which is opensource, you can rewrite it to
anything you want.
Sep 28 2011
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I got the point.
This boils down to the same issue of "is the feature worth changing
the language".
a GraphicsCardAllocator would still be very useful, even if it would
force you to use custom array types.

I looked at the programming paradigms, that D added on top of those,
taken from C++, including improved generic programming, generative
programming, functional programming...
And thought, that it would be a very good idea to add
hardware-distributed programming.
Even if it would be purely library solution.
What i mean is an integration of D with OpenCL: a very easy way to
switch the memory and processing between required devices.
We could have a compile-time functions, that translate D code into
OpenCL kernels and perform all necessary setup at program start-up.
You'd feed the D modules in the templates and the templates would
generate the necessary code to make the module run on desired
hardware.
We all know, that an OpenCL binding for D will come along eventually
(if not already done).
It would be very nice to further improve it's usability, using D's
unique language features.

What do you think?

On Wed, Sep 28, 2011 at 2:47 PM, Kagamin <spam here.lot> wrote:

 Gor Gyolchanyan Wrote:


 I have a question about switching to 100% manual memory management.
 I know how it should be done with structs and classes: override the
 new and delete.
 But i don't know how to do it for arrays, associative arrays, stack
 frames for delegates and all other instances of implicit memory
 allocation.
 Is there a way to completely override all memory allocations, so that
 i can use the language to the fullest in performance-critical places?

 Cheers,
 Gor.


 allocation is done by druntime, which is opensource, you can rewrite it to
anything you want.
Sep 28 2011
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Wed, 28 Sep 2011 13:12:39 +0200, Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com> wrote:


 I got the point.
 This boils down to the same issue of "is the feature worth changing
 the language".
 a GraphicsCardAllocator would still be very useful, even if it would
 force you to use custom array types.


You can use any raw memory as array using the pointer slice expression.
Appending won't work out of the box of course.
Have a look at druntime rt.lifetime. You could possibly write a gc proxy  
wrapper
and add a flag to the BlkInfoAttr. Then you're able to intercept those  
(re)allocations.



 I looked at the programming paradigms, that D added on top of those,
 taken from C++, including improved generic programming, generative
 programming, functional programming...
 And thought, that it would be a very good idea to add
 hardware-distributed programming.
 Even if it would be purely library solution.
 What i mean is an integration of D with OpenCL: a very easy way to
 switch the memory and processing between required devices.
 We could have a compile-time functions, that translate D code into
 OpenCL kernels and perform all necessary setup at program start-up.
 You'd feed the D modules in the templates and the templates would
 generate the necessary code to make the module run on desired
 hardware.
 We all know, that an OpenCL binding for D will come along eventually
 (if not already done).
 It would be very nice to further improve it's usability, using D's
 unique language features.

 What do you think?

 On Wed, Sep 28, 2011 at 2:47 PM, Kagamin <spam here.lot> wrote:

 Gor Gyolchanyan Wrote:


 I have a question about switching to 100% manual memory management.
 I know how it should be done with structs and classes: override the
 new and delete.
 But i don't know how to do it for arrays, associative arrays, stack
 frames for delegates and all other instances of implicit memory
 allocation.
 Is there a way to completely override all memory allocations, so that
 i can use the language to the fullest in performance-critical places?

 Cheers,
 Gor.


 allocation is done by druntime, which is opensource, you can rewrite it  
 to anything you want.
Sep 28 2011
prev sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Great idea! I never new, that it's possible to intercept GC calls!

On Wed, Sep 28, 2011 at 4:18 PM, Martin Nowak <dawg dawgfoto.de> wrote:

 On Wed, 28 Sep 2011 13:12:39 +0200, Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com> wrote:


 I got the point.
 This boils down to the same issue of "is the feature worth changing
 the language".
 a GraphicsCardAllocator would still be very useful, even if it would
 force you to use custom array types.


 You can use any raw memory as array using the pointer slice expression.
 Appending won't work out of the box of course.
 Have a look at druntime rt.lifetime. You could possibly write a gc proxy
 wrapper
 and add a flag to the BlkInfoAttr. Then you're able to intercept those
 (re)allocations.



 I looked at the programming paradigms, that D added on top of those,
 taken from C++, including improved generic programming, generative
 programming, functional programming...
 And thought, that it would be a very good idea to add
 hardware-distributed programming.
 Even if it would be purely library solution.
 What i mean is an integration of D with OpenCL: a very easy way to
 switch the memory and processing between required devices.
 We could have a compile-time functions, that translate D code into
 OpenCL kernels and perform all necessary setup at program start-up.
 You'd feed the D modules in the templates and the templates would
 generate the necessary code to make the module run on desired
 hardware.
 We all know, that an OpenCL binding for D will come along eventually
 (if not already done).
 It would be very nice to further improve it's usability, using D's
 unique language features.

 What do you think?

 On Wed, Sep 28, 2011 at 2:47 PM, Kagamin <spam here.lot> wrote:

 Gor Gyolchanyan Wrote:


 I have a question about switching to 100% manual memory management.
 I know how it should be done with structs and classes: override the
 new and delete.
 But i don't know how to do it for arrays, associative arrays, stack
 frames for delegates and all other instances of implicit memory
 allocation.
 Is there a way to completely override all memory allocations, so that
 i can use the language to the fullest in performance-critical places?

 Cheers,
 Gor.


 allocation is done by druntime, which is opensource, you can rewrite it
 to anything you want.
Sep 28 2011