3 ms·

Garbage collection is actually faster than generic malloc for allocating memory because it can work as a simple bump allocator. And there are ways to handle col

Garbage collection is actually faster than generic malloc for allocating memory because it can work as a simple bump allocator. And there are ways to handle collection efficiently. Malloc is also not entirely deterministic in performance because the heap can get fragmented. Either way, if latency matters you end up having to care about (de)allocation patterns at the app level.

nu11ptr 3y ago
Agreed, it seems weird to me to avoid garbage collection in a high level language. It is one thing to use escape analysis to avoid creating garbage, but mallocing every object is going be slower than a well tuned GC.
- couchand 3y ago
  > mallocing every object So don't do that then? Put most things on the stack. It's far faster than any allocation.
  - kaba0 3y ago
    That’s also true of a GCd language though.
  - nu11ptr 3y ago
    In the context of escape analysis (which would place many objects on the stack) that should have read: mallocing every _heap_ object
- estebank 3y ago
  I would say that in practice 80% of the values go on the stack, 18% in Box and 2% in an Arc/Rc. That's why Rust code tends to be fast: the common cases are really easy to represent with the borrow checker, so a hypothetical GC doesn't have to perform escape analysis to see if it is ok to specialise those allocations, while the more uncommon cases can still be represented, albeit more verbosely than a GCd language would need.
couchand 3y ago
I think most people's concern with GC is not the allocation side of it? And in any case alloca blows them all out of the water. > if latency matters you end up having to care about (de)allocation patterns at the app level. Yes, and you want tools that allow you to precisely describe your needs, which might be more difficult if a lumbering brute is standing between you and your data.
- hgs3 3y ago
  Most GC concerns surround "stop the world" tracing collectors that "pause" the program unpredictably for an indeterminate time. These collectors are bad for real-time and soft real-time applications for obvious reasons. They would do better with a reference counting collector because its GC bookkeeping is smeared predictably across the run of the program. Most languages don't use reference counting because most applications are either one-shot console apps, GUI apps, or web apps - the latter two operate on "bursts" of input. If your app operates in "bursts" then a tracing GC is superior since you can delay collection until the app is waiting for more input. Real-time apps don't have a moment where they "wait" therefore they should prefer reference counting for its predictable performance. You have to use the right GC algorithm for the right job, but unfortunately programming language runtimes don't usually offer a choice.

nu11ptr 3y ago

Agreed, it seems weird to me to avoid garbage collection in a high level language. It is one thing to use escape analysis to avoid creating garbage, but mallocing every object is going be slower than a well tuned GC.

couchand 3y ago
> mallocing every object So don't do that then? Put most things on the stack. It's far faster than any allocation.
- kaba0 3y ago
  That’s also true of a GCd language though.
- nu11ptr 3y ago
  In the context of escape analysis (which would place many objects on the stack) that should have read: mallocing every _heap_ object
estebank 3y ago
I would say that in practice 80% of the values go on the stack, 18% in Box and 2% in an Arc/Rc. That's why Rust code tends to be fast: the common cases are really easy to represent with the borrow checker, so a hypothetical GC doesn't have to perform escape analysis to see if it is ok to specialise those allocations, while the more uncommon cases can still be represented, albeit more verbosely than a GCd language would need.

couchand 3y ago

I think most people's concern with GC is not the allocation side of it? And in any case alloca blows them all out of the water. > if latency matters you end up having to care about (de)allocation patterns at the app level. Yes, and you want tools that allow you to precisely describe your needs, which might be more difficult if a lumbering brute is standing between you and your data.

hgs3 3y ago
Most GC concerns surround "stop the world" tracing collectors that "pause" the program unpredictably for an indeterminate time. These collectors are bad for real-time and soft real-time applications for obvious reasons. They would do better with a reference counting collector because its GC bookkeeping is smeared predictably across the run of the program. Most languages don't use reference counting because most applications are either one-shot console apps, GUI apps, or web apps - the latter two operate on "bursts" of input. If your app operates in "bursts" then a tracing GC is superior since you can delay collection until the app is waiting for more input. Real-time apps don't have a moment where they "wait" therefore they should prefer reference counting for its predictable performance. You have to use the right GC algorithm for the right job, but unfortunately programming language runtimes don't usually offer a choice.