On 7/17/2025 1:51 PM, Gregor Mückl wrote:
> This sounds like an interesting nwcpp meetup! Do I have to RSVP for in person attendance?

Nah, people just show up. I often bring friends with me.

On 7/25/25 4:38 PM, Walter Bright wrote:
> On 7/17/2025 10:04 AM, Ali Çehreli wrote:
>> Wow! I am planning to join online.
> 
> I was listening to the voice of a remote attendee asking questions, and I thought: Hey! That sounds just like Ali!
> 
> Glad you were there!
> 

I can't believe C++ was explained as moderately easy to learn. (I don't remember exact wording now.) There are smart people out there! ;)

Ali

On Thursday, 17 July 2025 at 08:30:01 UTC, Serg Gini wrote:
> On Thursday, 17 July 2025 at 07:12:46 UTC, Walter Bright wrote:
>> at 6pm I'll be representing D as a panelist.
>>
>> Details:
>>
>> https://nwcpp.org/
>>
>> "This month we will be hosting a joint meetup with the Rust User Group to discuss a breadth of programming languages with a panel of experts. In this talk we will compare and contrast: D, C++, Rust, Swift, Cpp2, C# and Mojo."
>
> In case somebody will say that "GC is slow"
> https://github.com/jinyus/related_post_gen

I don't want to be negative, just in order to remain factual: I don't see in what way this related_post_gen benchmark causes load on the GC. Also, the results don't list memory usage which renders it almost useless as a GC benchmark.

The binarytrees benchmark on https://programming-language-benchmarks.vercel.app/ is a good test for the GC. I'm aware of the discussion that this site to some extend does not compare the same things in their implementation of the respective programming languages. But it is quite striking to see that the D GC consumes a multiple of the memory some other GCes language like Crystal consumes:

https://programming-language-benchmarks.vercel.app/d-vs-crystal

Same picture wehen you compare D with Go or Java:

https://programming-language-benchmarks.vercel.app/d-vs-go
https://programming-language-benchmarks.vercel.app/d-vs-java

For the binarytrees benchmark you can see that the other languages must have a more efficient GC (cpu time lower, memory consumption lower ot both). In case of Java and Go that is acceptable to me. Both languages are being backed by multi billion companies and have very sophisticated GCs. But Crystal is a hobbyist open source language much simpler than D and its GC seem to perform much better.

On Thursday, 7 August 2025 at 10:10:05 UTC, Bienlein wrote:
> On Thursday, 17 July 2025 at 08:30:01 UTC, Serg Gini wrote:
>> On Thursday, 17 July 2025 at 07:12:46 UTC, Walter Bright wrote:
>>> at 6pm I'll be representing D as a panelist.
>>>
>>> Details:
>>>
>>> https://nwcpp.org/
>>>
>>> "This month we will be hosting a joint meetup with the Rust User Group to discuss a breadth of programming languages with a panel of experts. In this talk we will compare and contrast: D, C++, Rust, Swift, Cpp2, C# and Mojo."
>>
>> In case somebody will say that "GC is slow"
>> https://github.com/jinyus/related_post_gen
>
> I don't want to be negative, just in order to remain factual: I don't see in what way this related_post_gen benchmark causes load on the GC. Also, the results don't list memory usage which renders it almost useless as a GC benchmark.

Hi there. This message didn't mean that this benchmark is a proper GC load.
But it is the response to some group of people that are saying "This language has GC - it's slow. I don't want to use it".
So the point was that even the language with GC can be fast. If you use proper memory management techniques or in some tasks where memory is less important.

> The binarytrees benchmark on https://programming-language-benchmarks.vercel.app/ is a good test for the GC. I'm aware of the discussion that this site to some extend does not compare the same things in their implementation of the respective programming languages. But it is quite striking to see that the D GC consumes a multiple of the memory some other GCes language like Crystal consumes:
>
> https://programming-language-benchmarks.vercel.app/d-vs-crystal
>
> Same picture wehen you compare D with Go or Java:
>
> https://programming-language-benchmarks.vercel.app/d-vs-go
> https://programming-language-benchmarks.vercel.app/d-vs-java
>
> For the binarytrees benchmark you can see that the other languages must have a more efficient GC (cpu time lower, memory consumption lower ot both). In case of Java and Go that is acceptable to me. Both languages are being backed by multi billion companies and have very sophisticated GCs. But Crystal is a hobbyist open source language much simpler than D and its GC seem to perform much better.

Ok now about this code.
General rule - always compare code not only results.

D code for some slight improvements in performance is adding special rule to not grab garbage that lower than 300 Mb.
Without this GC setting the memory consumption will drop to 60-70 Mb.

D's GC also has some other settings that can be tuned for better results.

Also different languages have different default conditions. For example, C# is allocating initially quite a big chunk of memory, which helps them to have better results on such GC-stressful tasks.

Also keep in mind, that this website is prohibiting direct use of Arenas, while some languages are using them internally.
All these tradeoffs of internal implementations can help them to have higher values in some tasks (like binarytrees problem), but at the same time show worse results in other tasks.

And last, but not least there are of course other ways to solve this problem.

https://github.com/BinaryTrees
You can find D solution that should outperform the one that available in programming-benchmark-game.
They are just not in scope of the comparison. But for real problem - you are not locked withing "standard GC solution"

Languages like Java only do allocation on the GC. GC is very heavily used by Java programs. This makes the use of "write gates" practical.

D programs tend to only lightly use GC, and using "write gates" would speed up the GC collection cycle, but it would drastically slow down the rest of the code.

It's all tradeoffs.