4 ms·

> Virtual machines are an implementation detail and the latest versions with dynamic tiered JITers, POGO, vectorization, and other techniques can match or excee

> Virtual machines are an implementation detail and the latest versions with dynamic tiered JITers, POGO, vectorization, and other techniques can match or exceed static compilation because they optimize based on actual runtime behavior instead of assumptions. In theory, practice is like theory. In practice, it isn't. Maybe in 20 years, JITs can provide AOT-like throughput without significant memory / power consumption. Not with current tech, except on cherry picked benchmarks.

pjmlp 5y ago
Like this one, where .NET is capable to outperform Go and C++ for gRPC parsing? https://devblogs.microsoft.com/dotnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/dotnet/grpc-performance-impro... Or this one where JIT compilers beat Swift? https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
- fnord123 5y ago
  You keep posting a 2 year old msft blog post which is out of date. The benchmark project page they link to points to this for the most recent results: https://www.nexthink.com/blog/comparing-grpc-performance/ https://www.nexthink.com/blog/comparing-grpc-performance/ Note that akka is currently second for single core, and fastest with multicore. .Net has a nice result, but lets use up to date results. Especially when it still fits your argument that JIT can compete in benchmarks with suitable warmup, etc..
  - pjmlp 5y ago
    Maybe because I wasn't aware of other ones? Still it confirms the point that Go isn't up to the competition, which was my point, not that .NET is the super dupper best thing in the world.
  - manigandham 5y ago
    Your article shows that Java, Scala, and .NET are all faster than significantly faster than Go in latency and throughput, and can beat C++ as well. This only affirms our point that JIT can keep up with, or beat, AOT already.
    - blub 5y ago
      It can, after a warm-up period and by using 10x the memory and likely non-idiomatic code. Sometimes one can live with that, sometimes not.
      - pjmlp 5y ago
        Only when the users are clueless to configure JIT caches. As for non idiomatic code, that is even worse for Go code, as it lacks many of the performance tuning knobs.
      - kaba0 5y ago
        Look at benchmark game’s java programs - it is very idiomatic compared to most other contenders yet it is exceedingly fast
    - fnord123 5y ago
      I literally said this in my comment.
- deleted 5y ago
  [deleted]

pjmlp 5y ago

Like this one, where .NET is capable to outperform Go and C++ for gRPC parsing? https://devblogs.microsoft.com/dotnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/dotnet/grpc-performance-impro... Or this one where JIT compilers beat Swift? https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages

fnord123 5y ago
You keep posting a 2 year old msft blog post which is out of date. The benchmark project page they link to points to this for the most recent results: https://www.nexthink.com/blog/comparing-grpc-performance/ https://www.nexthink.com/blog/comparing-grpc-performance/ Note that akka is currently second for single core, and fastest with multicore. .Net has a nice result, but lets use up to date results. Especially when it still fits your argument that JIT can compete in benchmarks with suitable warmup, etc..
- pjmlp 5y ago
  Maybe because I wasn't aware of other ones? Still it confirms the point that Go isn't up to the competition, which was my point, not that .NET is the super dupper best thing in the world.
- manigandham 5y ago
  Your article shows that Java, Scala, and .NET are all faster than significantly faster than Go in latency and throughput, and can beat C++ as well. This only affirms our point that JIT can keep up with, or beat, AOT already.
  - blub 5y ago
    It can, after a warm-up period and by using 10x the memory and likely non-idiomatic code. Sometimes one can live with that, sometimes not.
    - pjmlp 5y ago
      Only when the users are clueless to configure JIT caches. As for non idiomatic code, that is even worse for Go code, as it lacks many of the performance tuning knobs.
    - kaba0 5y ago
      Look at benchmark game’s java programs - it is very idiomatic compared to most other contenders yet it is exceedingly fast
  - fnord123 5y ago
    I literally said this in my comment.
deleted 5y ago
[deleted]