3 ms·

> I don't know a ton about low level performance, but I'd find it surprising if it's not true. How can interpreted bytecode outperform direct machine instructio

> I don't know a ton about low level performance, but I'd find it surprising if it's not true. How can interpreted bytecode outperform direct machine instructions? Because the JVM and .NET compile; they don't interpret bytecode.

kjksf 4y ago
That doesn't mean that JVM or .NET JIT is faster than Go compiled code. They will almost always be slower because they have 3 structural disadvantages. 1. Compilation bytecode => machine code happens at runtime so it's a constant overhead. There's also other overhead related to keeping invocation counts to decide when JIT should kick in. 2. Because compilation happens at runtime, they can't spend too much time on compilation so they are limited at how good the generated code can be. Go doesn't have those restrictions. 3. Modern performance is heavily influenced by memory use. By design JVM and .NET are more memory hungry. Every object in JVM has 8-16 bytes overhead compared to Go struct etc. Value types are relatively recent and not commonly used. In practice it adds up. The are 2 advantages of advanced JITs: 1. It can make better inlining decisions based on actual execution counts of a function vs. a heuristic in a Go compiler. (Go 1.20 will have preview of profile-guided optimization which provides the same optimization). 2. A generational GC used in most JVM / .NET implementation is faster for certain allocation patterns (high rate of allocations / frees) than Go's allocator. But your average Go program will be both faster and significantly less memory hungry than your average Java / .NET program. The memory overhead is especially bad for Java / .NET. Go only compiles the functionality used. Java / .NET have very heavy runtimes / standard libraries that are packaged into one library and have to be loaded into memory. What it means in practice is: I can run a Go server comfortably on the cheapest shared server with 512 MB and a Java / .NET server would push it to the limit.
- kaba0 4y ago
  A managed language directly trades away memory usage for CPU time and vice versa. Go using less memory only means it will have worse throughput.
- pjmlp 4y ago
  .NET has had Go like structs since 2001. Value types in .NET exist since 2001. .NET has unsafe since 2001. .NET has had AOT since 2001 with NGEN. C++ is one of the supported languages on .NET since 2001. Please educate yourself on the platforms, before criticising them.

kjksf 4y ago

That doesn't mean that JVM or .NET JIT is faster than Go compiled code. They will almost always be slower because they have 3 structural disadvantages. 1. Compilation bytecode => machine code happens at runtime so it's a constant overhead. There's also other overhead related to keeping invocation counts to decide when JIT should kick in. 2. Because compilation happens at runtime, they can't spend too much time on compilation so they are limited at how good the generated code can be. Go doesn't have those restrictions. 3. Modern performance is heavily influenced by memory use. By design JVM and .NET are more memory hungry. Every object in JVM has 8-16 bytes overhead compared to Go struct etc. Value types are relatively recent and not commonly used. In practice it adds up. The are 2 advantages of advanced JITs: 1. It can make better inlining decisions based on actual execution counts of a function vs. a heuristic in a Go compiler. (Go 1.20 will have preview of profile-guided optimization which provides the same optimization). 2. A generational GC used in most JVM / .NET implementation is faster for certain allocation patterns (high rate of allocations / frees) than Go's allocator. But your average Go program will be both faster and significantly less memory hungry than your average Java / .NET program. The memory overhead is especially bad for Java / .NET. Go only compiles the functionality used. Java / .NET have very heavy runtimes / standard libraries that are packaged into one library and have to be loaded into memory. What it means in practice is: I can run a Go server comfortably on the cheapest shared server with 512 MB and a Java / .NET server would push it to the limit.

kaba0 4y ago
A managed language directly trades away memory usage for CPU time and vice versa. Go using less memory only means it will have worse throughput.
pjmlp 4y ago
.NET has had Go like structs since 2001. Value types in .NET exist since 2001. .NET has unsafe since 2001. .NET has had AOT since 2001 with NGEN. C++ is one of the supported languages on .NET since 2001. Please educate yourself on the platforms, before criticising them.