Chris R Miller schrieb:
Trass3r wrote:
Is there any tutorial or code for using CUDA with D?
Short answer: no.
I looked into writing CUDA with D a while back. The problem is that the
CUDA C runtime and the D runtime are 100% incompatible. CUDA works by
taking C-like code and compiling it
Lutger schrieb:
I think OpenCL will be easier and work om AMD to boot.
If they ever release it in the next few months ;)
I'm writing some performance sensitive code (real time processing) for which
I've tried to minimize the number of memory allocations by using preallocated
objects pools. Unfortunately, during the course of running, it seems that lots
of memory is still getting allocated even though all
On Tue, Feb 24, 2009 at 12:00 PM, wade Shen swadena...@gmail.com wrote:
I'm writing some performance sensitive code (real time processing) for which
I've tried to minimize the number of memory allocations by using preallocated
objects pools. Unfortunately, during the course of running, it
Reply to Jarrett,
Hm, actually..
If you *are* using D2, you might be able to replace the GC interface
with a debug interface that just forwards calls to the normal GC.
This is a capability druntime inherited from the Tango runtime - the
GC is separated from the rest of the standard library
On Tue, 24 Feb 2009 20:40:13 +0300, BCS a...@pathlink.com wrote:
Reply to Jarrett,
Hm, actually..
If you *are* using D2, you might be able to replace the GC interface
with a debug interface that just forwards calls to the normal GC.
This is a capability druntime inherited from the Tango
Thanks,
That's helpful. I'm using D 1.0. I've eliminated all array concats, dups,
etc. but there's still a significant amount of memory being allocated that I
can't seem to detect.
Perhaps, I can recompile an instrumented version of phobos...
wade
Jarrett Billingsley Wrote:
On Tue, Feb
Reply to wade,
Yes,
this would be a great idea, especially for RT production software.
wade
Denis Koroskin Wrote:
For production software it would get tricky. Are you better of doing the
alloc or just failing?
Jarrett Billingsley wrote:
On Tue, Feb 24, 2009 at 12:00 PM, wade Shen swadena...@gmail.com wrote:
I'm writing some performance sensitive code (real time processing) for
which I've tried to minimize the number of memory allocations by using
preallocated objects pools. Unfortunately, during
TSalm wrote:
I'm trying to build function which have the hability to convert a
type
to void* and from void*.
First of all, I have to ask: have you looked at std.variant /
tango.core.Variant?
Yes, but it seems that Variant class uses more memory than void* .
The Phobos Variant will use
wolftousen wrote:
I have a function defined as:
some_function(int[] array) { ... }; //this function does not ever modify
values of array
When I call this function (once every program cycle) from an object using an
array of type short:
//member variable in an object
short[] x =
TSalm wrote:
In my case, there's also no possibility to get the wrong type, because
it is managed by the type of the ColumnMem.
You still have to get the code right. There's a surprising number of
corner cases trying to store arbitrary types.
And about Object, if I want to store base type
Thanks again for all the help. I found what the problem was and it wasn't
obvious (at least to me):
float[uint] arr;
foreach (uint k; arr.keys)
{
...
}
Changing this to:
foreach (uint k, float v; arr)
{
...
}
fixes the leak. I guess the keys array is constructed on the fly?
wade
Lutger
On Tue, Feb 24, 2009 at 6:45 PM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Maybe it's because I just woke up, but I can't see how that code could
compile anyway, since you can't pass a short[] to a function expecting
an int[].
You missed the array literal.
On Tue, Feb 24, 2009 at 8:04 PM, wade swadena...@gmail.com wrote:
fixes the leak. I guess the keys array is constructed on the fly?
Oh, yes X| .keys and .values of AAs are constructed whenever you use them.
wade wrote:
Thanks again for all the help. I found what the problem was and it wasn't
obvious (at least to me):
float[uint] arr;
foreach (uint k; arr.keys)
{
...
}
Changing this to:
foreach (uint k, float v; arr)
{
}
fixes the leak. I guess the keys array is
On Tue, Feb 24, 2009 at 8:23 PM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Yup.
It's a pity that we don't have, oh I don't know, some sort of efficient
iterable interface that doesn't cause a heap allocation that the runtime
could use instead
Jarrett Billingsley wrote:
On Tue, Feb 24, 2009 at 6:45 PM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Maybe it's because I just woke up, but I can't see how that code could
compile anyway, since you can't pass a short[] to a function expecting
an int[].
You missed the array
Jarrett Billingsley wrote:
On Tue, Feb 24, 2009 at 8:23 PM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
Yup.
It's a pity that we don't have, oh I don't know, some sort of efficient
iterable interface that doesn't cause a heap allocation that the runtime
could use instead
19 matches
Mail list logo