[niclo]

Tried to run the benchmark on my laptop (with a Ryzen 5 3500U), got different results much closer to what I would expect normally:

==> Running benchmark for java_grpc_pgc_bench... Requests/sec: 25563.46

==> Running benchmark for cpp_grpc_mt_bench... Requests/sec: 31389.24

==> Running benchmark for dotnet_grpc_bench... Requests/sec: 25376.18

==> Running benchmark for go_grpc_bench... Requests/sec: 29158.60

==> Running benchmark for rust_tonic_st_bench... Requests/sec: 28120.25

Different images for the same language (java, rust, cpp) performed with similar if not worse results

[christophilus]

I think this makes sense. I suspect the core count makes a pretty big difference, especially for Go, given it’s optimized for multi core.

Edit: what were your latencies and memory stats like?

[niclo]

I didn't got the final report because of some error, those numbers were printed during the execution of the benchmark.

I executed it giving both the client and the server 4 CPUs, now I'm running it again with 180s duration and gonna update the original comment if I get to see the report or there is any significant change

[oscargrouch]

Optimized for multi-core safety in a safe way, but given the safety of the actor idiom may incur in more copies, it cant be compared to the speed of a implementation that are more complicated to implement, but will perform better at the end giving you can customize better for that particular scenario.

With C++ and Rust you will be able to implement this in a more optimized way as you can look for approaches that avoid copies which can be the main factor of a slow implementation, specially in multi-threaded scenarios.