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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 =

look on this idea (awesome btw) the more I think it should be just specia=

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=

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.

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.

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

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