On Wednesday, 25 November 2020 at 07:54:57 UTC, Araq wrote:
> This problem -- if it really comes up -- is not part of the reference counting mechanism at all. Manual memory management with free() calls produces exactly the same effect.

That's not true.  The problem with reference counting is that the deallocation happens behind your back, and can be difficult to reason about or occur inconsistently.  With manual free calls, everything happens explicitly, and you have more flexibility about it.

All this aside the fact that, for games, automatic memory management isn't competing with 'malloc', it's competing with custom arenas.  Where you can deallocate everything at once and not have to worry about tracing an object graph.

Malloc is fairly slow as is, and the overhead of reference counting on top of it is generally acceptable (esp. with optimizations), but rc still has pathological cases.

On Wednesday, 25 November 2020 at 07:58:13 UTC, ryuukk_ wrote:
> Unity moving to incremental GC

But they have the money for it. What would you charge for implementing one that is fine tuned for D?

I've given it some thought and concluded that it would be rather risky to take it on with less than 2 years pay... So if we do it as a collective spare time project it would take at least 5 to get to something that could even approach ARC. That's a very rough estimate. Maybe pessimistic, but the risk is that it leads to something unusable, and then you have wasted a lot of resources for nothing.

With ARC you can be certain that you have something that can complement manual strategies.

On Wednesday, 25 November 2020 at 07:58:13 UTC, ryuukk_ wrote:
> Unity moving to incremental GC
>
> https://www.youtube.com/watch?v=5Fks2NArDc0

I love the irony there.

Two top game engines in the world use garbage collection (Unity, Unreal), and the problem they _had_ is: a missed frame 60fps to 30fps (I wouldn't be able to see it). The example to show this is of course a FPS game where players can see this. It's not a common game genre to make for most companies if I understand.

That problem would probably be solvable will less memory allocation. But it hurts developer experience so the engine deals with that. "The GC is perfectly adequate in high-performance scenario" would be a logical conclusion.


BUT In the blogging and recruiting world though, Amazon will say on the AWS blog that
"Because Rust does not require a runtime or garbage collector, it is able to achieve runtime performance similar to C and C++."
https://aws.amazon.com/fr/blogs/opensource/why-aws-loves-rust-and-how-wed-like-to-help/

People really do like the idea that GC prevents top performance, disregarding that _Fortnite_ has a garbage collector.

On Wednesday, 25 November 2020 at 08:32:37 UTC, Elronnd wrote:
> On Wednesday, 25 November 2020 at 07:54:57 UTC, Araq wrote:
>> This problem -- if it really comes up -- is not part of the reference counting mechanism at all. Manual memory management with free() calls produces exactly the same effect.
>
> That's not true.  The problem with reference counting is that the deallocation happens behind your back, and can be difficult to reason about or occur inconsistently.  With manual free calls, everything happens explicitly, and you have more flexibility about it.
>

That's about implicit vs explicit code, still not about the refcounting mechanism. And the flexibility remains in the implicit code, move an owner to a different thread/owning data structure.

> All this aside the fact that, for games, automatic memory management isn't competing with 'malloc', it's competing with custom arenas.  Where you can deallocate everything at once and not have to worry about tracing an object graph.
>
> Malloc is fairly slow as is, and the overhead of reference counting on top of it is generally acceptable (esp. with optimizations), but rc still has pathological cases.

Areas still have pathological cases where you never free anything whatsoever in a runaway loop...

On Wednesday, 25 November 2020 at 09:05:16 UTC, Guillaume Piolat wrote:
> Two top game engines in the world use garbage collection (Unity, Unreal), and the problem they _had_ is: a missed frame 60fps to 30fps (I wouldn't be able to see it). The example to show this is of course a FPS game where players can see this.

I dont know. In my experience dropped frames are annoying in smooth artistic scenes. You want to suspend disbelief to create immersion.

On Wednesday, 25 November 2020 at 09:05:16 UTC, Guillaume Piolat wrote:
> On Wednesday, 25 November 2020 at 07:58:13 UTC, ryuukk_ wrote:
>> [...]
>
> I love the irony there.
>
> Two top game engines in the world use garbage collection (Unity, Unreal), and the problem they _had_ is: a missed frame 60fps to 30fps (I wouldn't be able to see it). The example to show this is of course a FPS game where players can see this. It's not a common game genre to make for most companies if I understand.
>
> [...]

+1. Couldn't have said it any better.

On Wednesday, 25 November 2020 at 09:36:41 UTC, Ola Fosheim Grostad wrote:
> I dont know. In my experience dropped frames are annoying in smooth artistic scenes. You want to suspend disbelief to create immersion.

btw, Ive had a lot if headaches over missed frames when doing even simple animations in browsers. Large objects with linear motion and high contrast makes missing frames very noticable. For some reason it looks even worse to me when objects move slow, probably because the object is more in focus and the eye tracks it better.

You can make it less noticable by adding blur and use less linear motion, but why should I have to waste hours on such tweaks just because the tech is shitty?

On Wednesday, 25 November 2020 at 08:25:33 UTC, Ola Fosheim Grostad wrote:
> On Wednesday, 25 November 2020 at 07:54:57 UTC, Araq wrote:
>> On Wednesday, 25 November 2020 at 07:43:23 UTC, Ola Fosheim Grostad wrote:
>>> ARC does not stop the world.
>>
>> He means the "unbounded" destruction phase when an enormous data structure needs to be free()d. This problem -- if it really comes up -- is not part of the reference counting mechanism at all. Manual memory management with free() calls produces exactly the same effect.
>
> It could happen in a game where you can teleport, but ARC can be combined with scene allocators. So if you delete the whole scene you would not need to deallocate individual objects.

Which is also possible alongside tracing GC implementations.

On Wednesday, 25 November 2020 at 10:24:28 UTC, Paulo Pinto wrote:
> Which is also possible alongside tracing GC implementations.

If it allows for separate pools.

On Wednesday, 25 November 2020 at 11:01:06 UTC, Ola Fosheim Grostad wrote:
> On Wednesday, 25 November 2020 at 10:24:28 UTC, Paulo Pinto wrote:
>> Which is also possible alongside tracing GC implementations.
>
> If it allows for separate pools.

Indeed, and I have used them in Go, Java and .NET, so D can easily do it.