4 ms·
It's interesting that the java ones use an order of magnitude more ram than rust. Is that just the overhead of being bytecode, or a different choice in processi
by mysterydip 6y ago
It's interesting that the java ones use an order of magnitude more ram than rust. Is that just the overhead of being bytecode, or a different choice in processing algorithm?
- vbsteven 6y agoIt likely counts the memory used by the JVM so it includes memory for the runtime, JIT, initial heap allocation, etc.
- jhgb 6y agoAlso both bytecode and the native code generated from bytecode are in memory at the same time, aren't they?
- vbsteven 5y agoYes, but it's more nuanced then that. If I remember correctly the bytecode is interpreted and executed by the runtime. This means the bytecode is fully in memory as bytecode when the jvm loads .class files. The native code for the JVM interpreter and runtime execution is also present in memory. At this point execution happens without "duplicate code" in memory. Note: the JVM could compile the bytecode fully into native code before execution but that's an implementation detail for a specific JVM implementation. Then we add the JIT. The JIT will notice hot paths during interpretation/execution and compile a method to native code and inject it so it calls the jit_native version instead of the bytecode_interpreted version. The JIT does not overwrite original bytecode but stores the compilation result separately. So to come back to your statement "both bytecode and native code generated from bytecode in memory at the same time": yes, but only for the JIT-compiled hot paths. This to me is the "power" of the JVM + JIT. Run interpreted bytecode and compile to native for the hot paths.
- oriolid 6y agoIt's because Rust frees memory at the moment it's not needed while Java runtime maintains a pool of memory and does garbage collection every now and then. This is a huge performance boost for code that does a lot of small allocations, and if you want to play dirty, reserving a large enough heap may allow you to run through a benchmark without a single garbage collection. Seriously, every now and then there's a story about some fintech company who use Java and use large enough heap that there's no garbage collection during stock market opening hours.
- mysterydip 6y agoInteresting, makes sense. So presumably if you ran the benchmark over a long enough time, performance would take a dive while the gc did its thing.
- oriolid 6y agoPossibly. I haven't tried running this benchmark with different heap sizes, but to me the 99% latency looks like it doesn't try to avoid GC. The JVM is really fast at memory management.
- kaba0 5y agoDuring the benchmark's duration, the GC was definitely ran. Java simply has really advanced GCs.
- steveklabnik 5y agoRust can do that but it also can not do that. You’d want to not do that here. That is, this is a library concern, not really a language one.