April 06

On Saturday, 6 April 2024 at 17:08:55 UTC, Sergey wrote:

>

On Saturday, 6 April 2024 at 16:59:14 UTC, Carl Sturtivant wrote:

>

On Saturday, 6 April 2024 at 16:28:25 UTC, Sergey wrote:

>

So what is the point then you wanted to discuss in this thread?

Finding strategic purpose via the future of GC.

D doesn't have any strategy.

As discussed, it needs to get some.

On Saturday, 6 April 2024 at 00:29:04 UTC, H. S. Teoh wrote:

>

On Sat, Apr 06, 2024 at 12:06:04AM +0000, Adam Wilson via

>

This is the point I was trying to make. The strategic win for have a fantastic GC would be immense, and would far outweigh anything we could gain by continuing down the no-GC path.

Totally. If we could introduce write barriers that opens the door to incremental generational GCs, that would be a HUGE step in the long run. Maybe not so much in the short term, but guys, it's been at least a decade. We gotta stop chasing decisions that only benefit the short term. It's time to think about long-term strategy.

April 06
On Saturday, 6 April 2024 at 16:49:44 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Modern GC's tend to need write barriers to make them work.

Write barrier can be as cheap as a single atomic write.
April 06
On Sat, Apr 06, 2024 at 07:09:12PM +0000, Sebastian Nibisz via Digitalmars-d wrote:
> On Saturday, 6 April 2024 at 16:49:44 UTC, Richard (Rikki) Andrew Cattermole
> wrote:
> > Modern GC's tend to need write barriers to make them work.
> 
> Write barrier can be as cheap as a single atomic write.

So let's do it!


T

-- 
The problem with the world is that everybody else is stupid.
April 06

On Saturday, 6 April 2024 at 14:53:09 UTC, Sergey wrote:

>

Very similar test..
D with LDC showed more FPS than Rust and C++ :P
https://github.com/NCrashed/asteroids-arena

This thing barely uses GC. It implements ECS architecture: all game entities are split into small components which are in separate arrays in a manner of an object pool pattern. And it utilizes std.container.Array to avoid GC.

Object pool may be good for performance, but’s also a form of manual memory management and therefore haram. GC bros want us to “just use GC”.

April 07

On Saturday, 6 April 2024 at 10:52:04 UTC, Ogi wrote:

>

I wrote a small script that simulates a video game. A game scene contains around ten thousand objects, and on every update it creates some new objects and destroys some old ones. It runs for 36,000 iterations (simulating 10 minutes of exciting 60 FPS gameplay) and measures minimum, mean and maximum time per update. One version uses GC, the other uses malloc/free.

This seems like an interesting benchmark. Can you post it somewhere?

April 07

On Saturday, 6 April 2024 at 21:04:03 UTC, Ogi wrote:

>

On Saturday, 6 April 2024 at 14:53:09 UTC, Sergey wrote:

>

Very similar test..
D with LDC showed more FPS than Rust and C++ :P
https://github.com/NCrashed/asteroids-arena

This thing barely uses GC. It implements ECS architecture: all game entities are split into small components which are in separate arrays in a manner of an object pool pattern. And it utilizes std.container.Array to avoid GC.

Object pool may be good for performance, but’s also a form of manual memory management and therefore haram. GC bros want us to “just use GC”.

The fallacy is to push for a XOR strategy instead of a OR strategy in regards to resource management.

The GC bros don't argue GC is the only strategy, only that it should be the default.

April 07
On 07/04/2024 7:09 AM, Sebastian Nibisz wrote:
> On Saturday, 6 April 2024 at 16:49:44 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Modern GC's tend to need write barriers to make them work.
> 
> Write barrier can be as cheap as a single atomic write.

*can be*

It would need to call into the GC as the strategy until we know what implementations need.

It must also be noted that dmd-be doesn't support atomics as intrinsics and Walter has been very against adding it, so it would still be a function call.
April 07
On Sunday, 7 April 2024 at 06:16:13 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 07/04/2024 7:09 AM, Sebastian Nibisz wrote:
>> On Saturday, 6 April 2024 at 16:49:44 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> Modern GC's tend to need write barriers to make them work.
>> 
>> Write barrier can be as cheap as a single atomic write.
>
> *can be*
>
> It would need to call into the GC as the strategy until we know what implementations need.
>
> It must also be noted that dmd-be doesn't support atomics as intrinsics and Walter has been very against adding it, so it would still be a function call.

Don't wait for Walter, you are capable, if you know how to do it, submit a PR

I'm pretty sure everyone wants atomics as intrinsics, myself included, just do it
April 07
On Saturday, 6 April 2024 at 19:09:12 UTC, Sebastian Nibisz wrote:
> On Saturday, 6 April 2024 at 16:49:44 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Modern GC's tend to need write barriers to make them work.
>
> Write barrier can be as cheap as a single atomic write.

Again, asking to become even worse than Java

Java's latest new concurrent GC doesn't need write barriers

Rust is the best evidence that nobody wants a system language with a GC, only Microsoft do, and they has lost
April 07
On 07/04/2024 9:41 PM, ryuukk_ wrote:
> On Sunday, 7 April 2024 at 06:16:13 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 07/04/2024 7:09 AM, Sebastian Nibisz wrote:
>>> On Saturday, 6 April 2024 at 16:49:44 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>>> Modern GC's tend to need write barriers to make them work.
>>>
>>> Write barrier can be as cheap as a single atomic write.
>>
>> *can be*
>>
>> It would need to call into the GC as the strategy until we know what implementations need.
>>
>> It must also be noted that dmd-be doesn't support atomics as intrinsics and Walter has been very against adding it, so it would still be a function call.
> 
> Don't wait for Walter, you are capable, if you know how to do it, submit a PR
> 
> I'm pretty sure everyone wants atomics as intrinsics, myself included, just do it

I don't know how to do it and have zero desire to learn that backend to that point, let alone how to introduce such intrinsics.

I know enough of x86 assembly to be dangerous, but over all have very little experience with backends. There are better ways for me to contribute.