> while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB
How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?
How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?
* Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves.
* Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code.
* A tracing garbage collector needs about five times as much memory as explicit freeing to reach the same performance. https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...
* Like vegetarians, Rustaceans pay more attention to efficiency as a whole. This may give the appearance of Rust being more efficient, even if it's actually not.
Your fourth point is the primary reason.
The GC in the JVM is set to try to waste as much RAM as possible. If you tune the GC you can get a big improvement and the standard Java Frameworks are bloated and slow as hell.
In my opinion it's a platform that is bad by default and simply isn't worth using but companies don't care and just buy more RAM.
Just a small nit but the term you're looking for here is "value types". Rust does heap allocations(with the pointer overhead) via Box<T>, you just get explicit control over the overhead and cost.
With Java 9 modularity and lightweight libraries like Guice you can get much nimbler apps.
Of course there have been some advanced in GC technology since 2005 (and that paper was deliberately measuring a relatively standard generational approach). But I don’t think I’d call the 5x figure a serious exaggeration.
So like I said, maybe in 2005 a 3x memory overhead only incurred 17% slowdown, but 3x overhead is at least at par, and possibly even a little ahead, of manual memory management.
It's not really a useful comparison for most uses of java though.
Often times people will give the JVM a sizeable heap in the interests of reducing garbage collector pressure (sometimes this is counterproductive). Usually it's possible to run with a much smaller heap, but we're still talking 100's of megabytes for most non-trivial apps. Even the VM itself will allocate a decent amount of memory besides that.
There's a number of reasons that typical JVM apps use more memory, but most of it seems to boil down to using the heap much more, lack of real value types (using the stack far less), and size overhead with small objects (see: https://www.javamex.com/tutorials/memory/object_memory_usage...).
It seems like the low cost cloud instances could be a real driver for the adoption of more lean runtimes. My client couldn't even consider those 256m/512m Heroku instances (with a large legacy JVM app).
Having a way-too-big heap is usually actively undesirable; you'll get fewer pauses, but much longer ones.
The claim "for equivalent Java code", might be slightly exaggerated, but looking at the claim as a whole: "Rust is Tilde's Competitive Advantage", "bad tuning" is part of the point.
"bad tuning" usually means "no tuning". Which means they spent the time they could have been tuning and used it to build features instead, or optimize their code instead.
From that perspective I wouldn't use "bad tuning" as an argument for continuing to use Java.
With that said, that's an almost entirely useless benchmark, except as a testament to the amazing JIT compilation the JVM does. That the JVM with GC is capable of matching a compiled language specifically made to have efficient memory management at ANY heap size is positively astonishing!
(Also, of course, your main server uses "up to" 5 GiB? That's fucking great. Until it goes beyond 64 GiB, who even cares. Work on something that has a worthwhile monetary return..)
Additionally people often tune the JVM to avoid some startup costs which includes fixed heap sizes which prevents the JVM from returning memory to the OS.
On top of that there often are just plain bad programming practices like deserializing large files into memory instead of streaming them. I suspect that rust also attracts more performance-conscious developers that avoid such things. Or maybe it is applied in projects where "throw more hardware at it" is not a cost-effective measure and investing in more developer-hours is appropriate.
I have no doubt that a Rust app will generally be more memory-efficient, but ultimately for server applications that is really not something a lot of people care about because of the incredibly low cost of "just buying more".
I've seen this on a modded Minecraft server with a half dozen players connected. It would thrash over a gigabyte of memory every 5-10 seconds or so. I had to tweak the garbage collector to avoid performance hitches.
(FWIW, it’s an apples-to-oranges comparison from a compilation, linking, packaging, etc. perspective, but from an end-user perspective I think it’s a reasonable claim.)
And so what? If a language's natural form leads to FUBAR code, what else is to blame?