Concurrency comparison node, go and V

[jorgeluismireles]

After issue #25130 and benchmark I wanted to know where the time is spent calculating primes in node, go and V by using a lot of channels, threads or equivalent.

I found V's spawn using linux pthreads is relatively slow but also the channels synch accounts in the overall time. Next images worth than thousand words show the times (log) expected to get a new prime as blue bars and the times creating a new thread to participate calculating more primes as green bars.

First graph is node's, second go's and third V's:

• Blue bars: Time in nanoseconds the main thread waits to calculate every prime. Bar goes from the center of the log graph to the left. A new prime is added when all the filters available so far determine a counting number is prime. Red line a the left is the primes time average.
• Green bars: Time in nanoseconds used to create and run a new thread to filter larger primes. Bar goes from the center of the log bar to the right. Red line at the right is the filter time average.

The total time is around the sum of all blue and green bars.

Lang	Blue primes	Green filters	Seconds
Node	Grows gently	Small always	0.041
Go	Shows patterns	Small with spikes	0.013
V	More chaotic	Large with spikes	0.602

With such strategies, V can't compute in my system to say 5000 primes because the memory exhausts.

We could argue V's green time (pthreads) could be reduced once coroutines (photon library) works with current channels. But I think V channels themselves synch is an important issue to revise if we want the go/node speed. For instance, node blue times grows gently as if there is a control inside while go's blue times shows interesting patterns alternating times as a comb. V's blue times looks chaotic.

More details here with larger images.

[jorgeluismireles]

Java 21 (Threads and SynchronousQueue) is 2-3 times faster than V 0.4.11

[JalonSolov]

Hopefully, you're compiling the V code with -prod.

At any rate, V is still a Beta level language. Very little work has been put into optimization, except allowing for the C compiler to do what it can.

[jorgeluismireles]

Not yet prod though I found the relative timing similar than those in the benchmark pages where is shown results for optimal code and statistics are better. Next thing I expect is someone could make to work photon lib with current channels to compare against pthreads.

[JalonSolov]

I wouldn't expect the code to work very well with the default tcc compiler - it doesn't do any useful optimizations, either. That's why I mentioned compiling with -prod.

[JalonSolov]

This is especially important when comparing V against code from other languages, since they almost all do optimizations.

[jorgeluismireles]

Benchmark page says V compilation was v/clang 0.4.11 and v/clang+gc 0.4.11. I did a v -prod -gc none primes.v and get a 94k exe. But running against the tcc version sometimes is faster 20%, others times same others worse. This algorithm is random, you need several tries but with these green bars at least I can see certain patterns with the concurrency methods used by every language. Right now I am reading Java 21 add virtual threads, so a lot of new language threads are "mounted" over former platform threads so this helps with speed when a lot of threads are spawned. AFAIK V approach is every spawn calls a platform pthread_create directly and has no "virtual threads" yet. Java synch queues (channels equivalent) are the other part where the time is invested.

[jorgeluismireles]

Rust 1.89.0 (async_std) is fast: