Oh, my GoD! Goroutines on D

[Sebastiaan Koppe]

On Thursday, 2 January 2025 at 19:59:26 UTC, Jin wrote:
>>> received 100000000 messages in 2906 msec sum=4999999950000000 
>>> speed=34411 msg/msec
>>> so, it's ~2.7x faster than Java:
>>> https://github.com/mingwugmail/liblfdsd/tree/master/comparison
>>> And your https://github.com/nin-jin/go.d on my machine
>>> go.d is 2~4 times slower than Go.
>>> 9.7638ms (Go) v.s [19 ms ~ 40 ms] (go.d)
>
> Hello everyone, I've done a little refactoring and optimization 
> of [jin.go](https://github.com/nin-jin/go.d):
> - I got rid of the vibe.d dependency because it's slow, big, 
> and I haven't been able to make friends with version 2. When 
> running only 1000 vibe-fibers, not only did the application 
> crash, but even the graphics system driver crashed once, which 
> required restarting the laptop.
> - So far, I've settled on native streams with a small stack 
> size (4 kb).
> - I'm really looking forward to 
> [photon's](https://github.com/nin-jin/go.d/issues/7) 
> stabilization to get fiber support back. It would be really 
> awesome to see it in the standard library.
> - I had to abandon the move semantics because I couldn't make 
> friends with the delegates. Currently, the number of references 
> to the queue is controlled by the copy constructor.
>
> Good news! After all the optimizations, the channels show 
> impressive speed in the above benchmark for pumping messages 
> between two streams.

Since you are essentially testing the speed of your spsc ring 
queue, I would just benchmark the queue directly. Don't think 
there is much room for improvement unless you adopt disruptor 
design and switch to batch consumption. That said, I do see some 
redundant offset loads and stores in the code the optimiser might 
miss.

Testing just the queue might also simplify and reduce the surface 
area to find the error.