April 06

On Saturday, 6 April 2024 at 01:31:33 UTC, zjh wrote:

>

On Sunday, 31 March 2024 at 14:22:43 UTC, Adam wrote:

>

I think if you like GC, you can try openD, which is pure GC.
As for D, if it's purely GC, why don't others use Rust? Are you prepared to completely abandon for system scope?.

Because it's not purely GC, nor is it intended to go that direction. I use the no-GC features occasionally, I don't need a pure-GC language. Just need a GC that doesn't suck compared to C#/Java.

April 06
On 06/04/2024 1:29 PM, H. S. Teoh wrote:
>     Chasing no-GC as far as we did was a mistake that cost us precious
>     time and scarce resources. We need to be mature enough to admit that
>     it was a mistake and correct our course. Given the lessons and
>     direction of the industry over the intervening years, I would
>     strongly argue that now is the time to return our focus to the GC. [...]
> 
> 
> +100. While there /have/ been improvements in our current GC over the past years, we're running against a brick wall in terms of available GC algorithms, because of the pessimistic situation of no write barriers. That closes the door to many of the major advancements in GC algorithms over the past decade or two. It's time we stop sitting on the fence and commit to a GC-centric language that actually has a competitive GC to speak of, one on the level of Java or C#'s incremental generational GCs.

It is not an all or nothing situation.

We can have write barriers be opt-in, and if all binaries have it, then the GC can take advantage of it.

The only person that needs convincing now is the one that does the work.
April 06

On Saturday, 6 April 2024 at 01:55:47 UTC, Adam Wilson wrote:

>

Because it's not purely GC, nor is it intended to go that direction. I use the no-GC features occasionally, I don't need a pure-GC language. Just need a GC that doesn't suck compared to C#/Java.

You don't have to worry at all, they have discussed it hundreds of times..

April 06
>

Many developers opposed to garbage collection are building “soft” real-time systems. They want to go as fast as possible—more FPS in my video game! Better compression in my streaming codec! But they don’t have hard latency requirements. Nothing will break and nobody will die if the system occasionally takes an extra millisecond.

This depends on the amount of latency. If it’s only “an extra millisecond” than yeah, not an issue. But if garbage collection can take more than entire game tick, than it’s a no-go.

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.

No-GC version completed the task in 15 seconds, giving a mean update time of 0.4 ms. Maximum was 1 ms.

Naïve GC version took 6 minutes, 40 secs; mean update time was 11 ms. Maximum was 34 milliseconds. That’s two entire updates in a game that runs at 60 updates per second. At some points the game cannot maintain 60 updates per second, dropping to up to 45. Not frames—I’m not rendering anything. Updates. The whole game just slows down.

Profiler reported around 12k collections. Collections could run multiple times during a single update, killing performance. Disabling GC for the duration of game update and calling GC.collect manually was a big improvement. Simulation took 1 minute 37 seconds, mean update time is therefore 2.7 ms. Maximum is 27 ms, which means occasional framerate drops. Well, at least the game can run at full speed...

So the GC is causing significantly worse performance and worse user experience than simple malloc. I don’t even have to use object pools or free lists or whatever. Do people who tell us that it’s fine to use use stop-the-world GC in “soft” real-time applications actually run some tests?

April 06

On Monday, 1 April 2024 at 20:45:25 UTC, Adam Wilson wrote:

>

Personally, I blame the OS/Game crowd for single-handedly keeping D out of the web service space for the past decade because, instead of improving the GC to the point that long-running processes are possible, we've built a mountain of (mis)features designed to assuage their demands.

If you want to write web things, the are many other program languages with established frameworks and tools, huge communities and corporate support. Perhaps it’s you who should consider a different language.

April 06

On Saturday, 6 April 2024 at 11:04:29 UTC, Ogi wrote:

>

On Monday, 1 April 2024 at 20:45:25 UTC, Adam Wilson wrote:

>

Personally, I blame the OS/Game crowd for single-handedly keeping D out of the web service space for the past decade because, instead of improving the GC to the point that long-running processes are possible, we've built a mountain of (mis)features designed to assuage their demands.

If you want to write web things, the are many other program languages with established frameworks and tools, huge communities and corporate support. Perhaps it’s you who should consider a different language.

Indeed, I would rather choose Java, Go, Oberon and C# for embedded development, as there is already several companies selling hardware and compiler toolchains, with companies paying real money for them.

Something that D has been missing out, by being stuck onto this kind of discussions.

April 06

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.

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

April 06

On Saturday, 6 April 2024 at 01:31:33 UTC, zjh wrote:

>

On Sunday, 31 March 2024 at 14:22:43 UTC, Adam wrote:

>

I think if you like GC, you can try openD, which is pure GC.

False.

>

As for D, if it's purely GC, why don't others use Rust?

Bogus assumption about D.

>

Are you prepared to completely abandon for system scope?.

Straw man.

None of the things you knock down are a part of the conversation in this forum thread. There is no "pure GC", and everything you said has been dealt with sanely in advance.

On Thursday, 4 April 2024 at 14:32:58 UTC, bachmeier wrote:

>

the problem is that the anti-GC zealots make the following claims:

  • The GC gets in the way. It needs to be removed the way Rust removed theirs for performance reasons.
  • D isn't suitable as a systems programming language because it has a GC.
  • GC should be removed as the default because it leads to bad practice.
  • All D programs have to use the GC.
April 06

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

>

Do people who tell us that it’s fine to use use stop-the-world GC in “soft” real-time applications actually run some tests?

Straw man. No-one told you "to use use stop-the-world GC in “soft” real-time" in this forum thread. The discussion was of an ace don't-stop-the-world GC as used by the author of the article linked to start this thread for real-world critical applications. And how D having THAT would be a game changer.

April 06

On Saturday, 6 April 2024 at 11:04:29 UTC, Ogi wrote:

>

On Monday, 1 April 2024 at 20:45:25 UTC, Adam Wilson wrote:

>

Personally, I blame the OS/Game crowd for single-handedly keeping D out of the web service space for the past decade because, instead of improving the GC to the point that long-running processes are possible, we've built a mountain of (mis)features designed to assuage their demands.

If you want to write web things, the are many other program languages with established frameworks and tools, huge communities and corporate support. Perhaps it’s you who should consider a different language.

Having a state-of-the-art ace GC of the effective-for-soft-real-time kind as per the article that started this forum thread would put D in a strong place in regard to web services too. Telling someone to leave D and not pursue this strategic future that they themselves are advocating is a bizarre to say the least. They're not just thinking tactically about the very next piece of web services coding.