3 ms·

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 ja

by niclo 5y ago

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 5y ago
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 5y ago
  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 5y ago
  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.