Rust performance with big memory consumption

help
1

Hi all,

When Java has a memory consumption of about 100GB it gets garbage collection is a real issue.
What would happen if this program would get ported to Rust. Would the rust memory management be affected by the size of the memory ?
As i understand there is no garbage collection in Rust but are there other factors ?

Thanks,

2

Rust does not have GC, but it's not magic. It could help you use less memory, but it depends on the type of the problem.

If your memory usage is high due to frequent allocation and deallocation of lots of objects that GC has to clean up, then Rust will likely have smaller peak memory usage. OTOH if you only need to allocate memory once and then keep it, it'll be similar.

In Java there may also be an overhead of using objects. If you're using lots of very small objects (smaller than 16 bytes), then Rust may help you pack your data more efficiently.

So to simplify "What would happen if this program would get ported to Rust" — it could use 50GB or memory, or could need closer to 100GB, depending on nature of the problem.

3 Likes
3

Hi,

May you please point me to a document which explains what the GC of Rust does and which parameters can be tuned?
I don't find it in a google search.

Thanks,

4

Rust does not have Garbage Collection.
I think he was speaking in general terms

1 Like
5

The answer is "it depends how the application de/allocates and uses that 100GB of memory".

If it's all allocated and also deallocated in one go then you'll notice the de/allocation times for sure.
But that's rather unlikely unless you use object pools I think, and if you are then during operation you may not notice any de/allocations at all other than the object pools being created during startup.

On the other end there is code that continually de/allocates, and if that happens on a large scale then you'll have poorly performing software regardless.

2 Likes
6

This mostly depends on the underlying allocator used, which is currently jemalloc. So maybe look at the characteristics of jemalloc to understand how a long-lived large-memory app might behave with Rust. The memory use will be lower with Rust because a GC like Java's always needs extra memory. The Java GC's scanning and accounting also needs extra time/memory which Rust won't need. One problem associated with long-lived large-memory apps with a normal C/C++ style allocator might be fragmentation of memory, but jemalloc works to avoid that.

1 Like
7

I'll add the following to what's already been said:

  1. GC precludes control and predictability. It generally won't trigger if you don't allocate, but once it does there's very little (if any) control over it. Crucially, it may go off doing its thing for a long time.
  2. How GC handles 100GB heaps will vary on GC implementation.
  3. Relatedly, allocation rate and its effect on promotion rate (in generational GCs) will have serious effect on performance.
  4. Object graph behind the 100GB is important. If you have 50 2GB primitive arrays vs 100000 1MB objects is going to matter.

But, large heaps are going to require careful memory management no matter what, GC or manual.

8

Another factor with big datasets is memory accesses locality. With Rust you can control (with a bit of work) your allocation patterns to avoid too much cache trashing, whereas in Java AFAIK you have to trust the allocator.