MM wrote:
> In article <e5ql8i$2abs$2@digitaldaemon.com>, Walter Bright says...
> 
>>AgentOrange wrote:
>>
>>>But what about array
>>>operations? Should one avoid using D arrays as well?
>>
>>I don't see why one would avoid them.
> 
> 
> Yes, could anybody pls explain why one should avoid using arrays for 'real'-time
> threads?
> (Also interested in creating a game engine in D)
> 
> 

byte[] A = new byte[128];
byte[] B = new byte[64];
A ~= B;

During the above concatenation, A will need to have 64 more bytes allocated for it to hold the extra elements from B.  Walter has said that when you allocate memory in D, with possible exceptions like that of C's malloc, a garbage collection may happen.  Therefore, a simple concatenation such as this could cause a garbage collection that may pause your game for seconds.  Actual time may vary, but it could be unacceptable.

You might be able to reduce the frequency of garbage collections by overallocating arrays, perhaps by doing something like
A.length = neededLength;
or
A.length = A.length * 2;
before you run your real-time code.  Then the copy of B would fit in A and no alloc would be needed.  You could eliminate the threat of a collection entirely by ensuring that no operations requiring new memory are called unless there is enough memory available to complete them without allocation.

I think you should be fine using arrays as long as you are careful with them.

Okay, so reading and writing to those arrays would not trigger gc, right? I can use arrays without malloc as long as I don't change it size, right? right? :D

MM wrote:
> Okay, so reading and writing to those arrays would not trigger gc, right?
> I can use arrays without malloc as long as I don't change it size, right?
> right? :D
> 
> 

Afaik, those things should be fine.

Only one other thing I can think of to watch out for at the moment:

byte[] A = new byte[128];
byte[] B = new byte[64];
A = B;

Once it executes A = B, the memory held by what was once A is leaked until a garbage collection occurs.  I'm not sure, but this could mean longer and more frequent garbage collections, unless you avoid allocating on the gc heap altogether for the rest of the program's execution.  This would call for some manual management, like so:

byte[] A = new byte[128];
byte[] B = new byte[64];
delete A;
A = B;

Just make sure there don't happen to be other references to A floating around in your program, or you are setting yourself up for disaster.

Also realize that you might be able to get away with using some GC. What I worry about is that I don't know how well this will work in a large game.  But as long as the garbage collections don't last long enough to be noticable, you are fine.

MM wrote:
> Okay, so reading and writing to those arrays would not trigger gc, right?

Right.

> I can use arrays without malloc as long as I don't change it size, right?
> right? :D

Right.

In article <e6kd4u$300u$1@digitaldaemon.com>, Chad J says...
>
>Once it executes A = B, the memory held by what was once A is leaked until a garbage collection occurs.  I'm not sure, but this could mean longer and more frequent garbage collections, unless you avoid allocating on the gc heap altogether for the rest of the program's execution.  This would call for some manual management, like so:
>
>byte[] A = new byte[128];
>byte[] B = new byte[64];
>delete A;
>A = B;

Wouldn't it be safe to say that if one were very pedantic about manually deleting everything they weren't using, that any pending GC cycle would be marginalized considerably?  After all, the GC spends a lot of its time figuring out what we already know at the point of deletion - that is, what is in use and what is not.

- EricAnderton at yahoo

pragma wrote:
> In article <e6kd4u$300u$1@digitaldaemon.com>, Chad J says...
>> Once it executes A = B, the memory held by what was once A is leaked until a garbage collection occurs.  I'm not sure, but this could mean longer and more frequent garbage collections, unless you avoid allocating on the gc heap altogether for the rest of the program's execution.  This would call for some manual management, like so:
>>
>> byte[] A = new byte[128];
>> byte[] B = new byte[64];
>> delete A;
>> A = B;
> 
> Wouldn't it be safe to say that if one were very pedantic about manually
> deleting everything they weren't using, that any pending GC cycle would be
> marginalized considerably?  After all, the GC spends a lot of its time figuring
> out what we already know at the point of deletion - that is, what is in use and
> what is not.

Yes.  And passing some type information to the GC would also help considerably.  Currently, the GC must assume all data could potentially be a pointer, while at the very least it should be possible for the GC to avoid scanning array data if the arrays don't contain object references or pointer types.  For games, such bulk data probably makes up a significant chunk of allocated storage.


Sean

Sean Kelly wrote:
> pragma wrote:
> 
>> In article <e6kd4u$300u$1@digitaldaemon.com>, Chad J says...
>>
>>> Once it executes A = B, the memory held by what was once A is leaked until a garbage collection occurs.  I'm not sure, but this could mean longer and more frequent garbage collections, unless you avoid allocating on the gc heap altogether for the rest of the program's execution.  This would call for some manual management, like so:
>>>
>>> byte[] A = new byte[128];
>>> byte[] B = new byte[64];
>>> delete A;
>>> A = B;
>>
>>
>> Wouldn't it be safe to say that if one were very pedantic about manually
>> deleting everything they weren't using, that any pending GC cycle would be
>> marginalized considerably?  After all, the GC spends a lot of its time figuring
>> out what we already know at the point of deletion - that is, what is in use and
>> what is not.
> 
> 
> Yes.  And passing some type information to the GC would also help considerably.  Currently, the GC must assume all data could potentially be a pointer, while at the very least it should be possible for the GC to avoid scanning array data if the arrays don't contain object references or pointer types.  For games, such bulk data probably makes up a significant chunk of allocated storage.
> 
> 
> Sean

Sounds like my decision to use arrays instead of pointers-to-data for all of my data (graphics and stuff traditionally done with pointers) is not just good, but very very good.  I originally decided on using arrays just to be able to use bounds-checking during a debug phase, but I take this as meaning it could be a big speed boost too!

Sean Kelly wrote:
> pragma wrote:
>> In article <e6kd4u$300u$1@digitaldaemon.com>, Chad J says...
>>> Once it executes A = B, the memory held by what was once A is leaked until a garbage collection occurs.  I'm not sure, but this could mean longer and more frequent garbage collections, unless you avoid allocating on the gc heap altogether for the rest of the program's execution.  This would call for some manual management, like so:
>>>
>>> byte[] A = new byte[128];
>>> byte[] B = new byte[64];
>>> delete A;
>>> A = B;
>>
>> Wouldn't it be safe to say that if one were very pedantic about manually
>> deleting everything they weren't using, that any pending GC cycle
>> would be
>> marginalized considerably?  After all, the GC spends a lot of its time
>> figuring
>> out what we already know at the point of deletion - that is, what is
>> in use and
>> what is not.
> 
> Yes.  And passing some type information to the GC would also help considerably.  Currently, the GC must assume all data could potentially be a pointer, while at the very least it should be possible for the GC to avoid scanning array data if the arrays don't contain object references or pointer types.  For games, such bulk data probably makes up a significant chunk of allocated storage.
> 
> 
> Sean

I believe the Boehm GC has such an alloc function.  I think they call it "atomic" data or somesuch.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

In article <e6nl5h$1kcj$1@digitaldaemon.com>, Daniel Keep says...
>
[snip]
>> Yes.  And passing some type information to the GC would also help considerably.  Currently, the GC must assume all data could potentially be a pointer, while at the very least it should be possible for the GC to avoid scanning array data if the arrays don't contain object references or pointer types.  For games, such bulk data probably makes up a significant chunk of allocated storage.
>> 
>> 
>> Sean
>
>I believe the Boehm GC has such an alloc function.  I think they call it "atomic" data or somesuch.

Didn't someone post a hack/mod to do just this over a year ago to the newsgroup?


If memory serves, all it did was somehow hint to the GC on new that the allocated block doesn't contain pointer data - as you both have suggested.  It did this transparently, by using D's type information.

- EricAnderton at yahoo

pragma wrote:
> In article <e6nl5h$1kcj$1@digitaldaemon.com>, Daniel Keep says...
> [snip]
>>> Yes.  And passing some type information to the GC would also help
>>> considerably.  Currently, the GC must assume all data could potentially
>>> be a pointer, while at the very least it should be possible for the GC
>>> to avoid scanning array data if the arrays don't contain object
>>> references or pointer types.  For games, such bulk data probably makes
>>> up a significant chunk of allocated storage.
>> I believe the Boehm GC has such an alloc function.  I think they call it
>> "atomic" data or somesuch.
> 
> Didn't someone post a hack/mod to do just this over a year ago to the newsgroup? 
> 
> If memory serves, all it did was somehow hint to the GC on new that the
> allocated block doesn't contain pointer data - as you both have suggested.  It
> did this transparently, by using D's type information.

Yeah, I remember that as well.  Haven't taken the time to try and find the NG posts about it though.


Sean