On Monday, 23 November 2020 at 13:53:04 UTC, rikki cattermole wrote:
> On 24/11/2020 2:31 AM, Ola Fosheim Grøstad wrote:
>> Alright! So now we need a high quality portable GUI framework that also can be used for turn based games.
>
> I'm working on it.
>
> Problem is I'm starting all the way back at colorimetry. A fascinating deep subject that pretty much every organization in the industry has their own thing on (as I say, you implement a dozen color spaces and now you need to implement two dozen more).

Haha! Yea, I've spent a lot of time reading about this topic. Very interesting. And it is fun how many image rescaling applications get gamma wrong! :-D Of course, anyone who has written their own toy raytracer understands gamma (as you use linear intensity during computations).

I think you can start by assuming sRGB as the default, though.

On Monday, 23 November 2020 at 13:29:58 UTC, Jacob Carlborg wrote:
> On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole wrote:
>
>> Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.
>
> FYI, `fork` is not available on iOS, tvOS and watchOS.
>
> --
> /Jacob Carlborg

Actually on macOS latest I had problems with program that ask for the current directory with `absolute`. I guess the cwd could be used for a side-channel attack somehow.

On Monday, 23 November 2020 at 13:29:58 UTC, Jacob Carlborg wrote:
> On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole wrote:
>
>> Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.
>
> FYI, `fork` is not available on iOS, tvOS and watchOS.
>
> --
> /Jacob Carlborg

And I've said this every time the word "fork" is mentioned: We cannot use forking methods on consoles. This will not realistically change in your lifetime.

This is a step in the right direction, but as usual, when will we see the results?

- GC that doesn't eat my precious memory

- GC that doesn't stop the world

- GC that doesn't affect the frame budget for a game


That is it, requirements are simple

I agree and i hear, GC is welcome in D, so be proud of it, and make it great! if nobody can, then drop it and implement some sort of ARC/RC what ever it is called, that would be better than having something that stop the world

Whoever has GC knowledge, open a patreon account and i'll give you my money

On Wednesday, 25 November 2020 at 05:55:39 UTC, ryuukk_ wrote:
> This is a step in the right direction, but as usual, when will we see the results?
>
> - GC that doesn't eat my precious memory
>
> - GC that doesn't stop the world
>
> - GC that doesn't affect the frame budget for a game
>
>
> That is it, requirements are simple
>
> I agree and i hear, GC is welcome in D, so be proud of it, and make it great! if nobody can, then drop it and implement some sort of ARC/RC what ever it is called, that would be better than having something that stop the world
>
> Whoever has GC knowledge, open a patreon account and i'll give you my money

ARC/RC also stops the world, hence the typical optimization to move the referenced data to a background thread when the reference count reaches zero for cleanup, and use of deferred/hazardous pointers.

Which when coupled with a couple of other optimizations, it becomes hardly indistinguishable from basic tracing GC algorithms.

On Wednesday, 25 November 2020 at 06:21:21 UTC, Paulo Pinto wrote:
>
> ARC/RC also stops the world, hence the typical optimization to move the referenced data to a background thread when the reference count reaches zero for cleanup, and use of deferred/hazardous pointers.
>
> Which when coupled with a couple of other optimizations, it becomes hardly indistinguishable from basic tracing GC algorithms.

Except that it's an algorithm oblivious to the involved heap sizes. And that it doesn't require heuristics how to handle the different "generations" (as there are none). And that it requires much less memory. And that it works well with custom destructors.

On Wednesday, 25 November 2020 at 06:21:21 UTC, Paulo Pinto wrote:
> ARC/RC also stops the world, hence the typical optimization to move the referenced data to a background thread when the reference count reaches zero for cleanup, and use of deferred/hazardous pointers.

ARC does not stop the world.
Algorithms that need hazard should do their own.

ARC should be as light as it can be. D is for systems programming.

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.

Unity moving to incremental GC

https://www.youtube.com/watch?v=5Fks2NArDc0

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.