On 29.12.2013 23:27, Walter Bright wrote:
> On 12/29/2013 2:10 PM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Sunday, 29 December 2013 at 21:39:52 UTC, Walter Bright wrote:
>>> Since you can control if and when the GC runs fairly simply, this is
>>> not any
>>> sort of blocking issue.
>
> Your reply doesn't take into account that you can control if and when
> the GC runs fairly simply. So you can run it at a time when it won't
> matter to the cache.
>


Better give up, I learned since the Oberon days that GC phobia will take few generations of programmers to wither away.


--
Paulo

On Sunday, 29 December 2013 at 22:27:43 UTC, Walter Bright wrote:
> Your reply doesn't take into account that you can control if and when the GC runs fairly simply. So you can run it at a time when it won't matter to the cache.

In a computer game GC should run frequently. You don't want to waste memory that could be used to hold textures on GC headroom. Realtime audio applications should run for 1 hour+ with absolutely no hiccups and very low latency.

Working around the limitations of a naive GC implementation is probably more work than it is worth.

On 12/29/13 3:14 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Sunday, 29 December 2013 at 22:27:43 UTC, Walter Bright wrote:
>> Your reply doesn't take into account that you can control if and when
>> the GC runs fairly simply. So you can run it at a time when it won't
>> matter to the cache.
>
> In a computer game GC should run frequently. You don't want to waste
> memory that could be used to hold textures on GC headroom. Realtime
> audio applications should run for 1 hour+ with absolutely no hiccups and
> very low latency.
>
> Working around the limitations of a naive GC implementation is probably
> more work than it is worth.

Then don't use the GC.

Andrei

On Sunday, 29 December 2013 at 23:58:34 UTC, Andrei Alexandrescu wrote:
> Then don't use the GC.

I agree!

Thus: any language that makes it hard to not use the GC is not competing with C++ as a performant language. ;-]

On 12/29/13 4:08 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Sunday, 29 December 2013 at 23:58:34 UTC, Andrei Alexandrescu wrote:
>> Then don't use the GC.
>
> I agree!
>
> Thus: any language that makes it hard to not use the GC is not competing
> with C++ as a performant language. ;-]

Oh brother.

Andrei

On Sunday, 29 December 2013 at 23:14:59 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 29 December 2013 at 22:27:43 UTC, Walter Bright wrote:
>> Your reply doesn't take into account that you can control if and when the GC runs fairly simply. So you can run it at a time when it won't matter to the cache.
>
> In a computer game GC should run frequently. You don't want to waste memory that could be used to hold textures on GC headroom. Realtime audio applications should run for 1 hour+ with absolutely no hiccups and very low latency.
>
> Working around the limitations of a naive GC implementation is probably more work than it is worth.

I work on a somewhat large game using D, there is no GC running because there are no allocations. As far as I know, people tend not to use system primitives like malloc/free in C++ games either as even those are too slow.

And why would you store textures in RAM?

On Monday, 30 December 2013 at 01:09:26 UTC, develop32 wrote:
> I work on a somewhat large game using D, there is no GC running because there are no allocations.

That's cool!

> As far as I know, people tend not to use system primitives like malloc/free in C++ games either as even those are too slow.

It is not uncommon to use your own allocator or only allocate big chunks, true.

> And why would you store textures in RAM?

Because you want to stream them to the GPU when you walk across the land in a seamless engine?

> Because you want to stream them to the GPU when you walk across the land in a seamless engine?

Indeed, but the arrays that are used for holding the data are allocated (not in GC heap) before the main loop and always reused.

> Indeed, but the arrays that are used for holding the data are allocated (not in GC heap) before the main loop and always reused.

Yes, I merely tried to point out that you don't want to spend a lot of memory for dead objects waiting for the GC to kick in. You can use that space for caching data or loading more detailed graphics. Besides you define a minimum amount of RAM that you game will work with and try to stay within those bounds in order to increase the market for your game, so you never have enough memory for the bottom line which is what you optimize for…

I assumed GC would be useful for AI/game world. It will benefit from GC because you have complex interdependencies, many different classes and want to be able to experiment. Experimentation and explicit memory deallocation is a likely source for memory leaks… However this will only work well with a basic GC if the AI/game world representation consists of relatively few objects. So it limits your design space.

I agree that GC isn't all that useful for graphics/audio because you have a small set of classes with simple relationships, so I never assumed you would want that.

> I assumed GC would be useful for AI/game world. It will benefit from GC because you have complex interdependencies, many different classes and want to be able to experiment. Experimentation and explicit memory deallocation is a likely source for memory leaks… However this will only work well with a basic GC if the AI/game world representation consists of relatively few objects. So it limits your design space.

I can imagine that, and I have been there in my C# days. I agree that its not a GC-friendly pattern. But then why use it in a language with a GC?

In my engine, world object (entity) is basically just a number. All of the entity data is stored in multiple components that are just functionless structs held in few global arrays. All of the game logic is done by separate managers.

In the end, AI/game logic uses the same mechanic as texture streaming - reuse of the previously allocated memory.