4 ms·

> The caveat is that properly engineered C/C++ hardly ever uses malloc() or similar to manage memory. "Properly engineered" probably isn't the right term. C/C

> The caveat is that properly engineered C/C++ hardly ever uses malloc() or similar to manage memory. "Properly engineered" probably isn't the right term. C/C++ code written for speed would not perform heap allocation in its main processing. However, this is true with garbage collected languages as well. Removing allocation means removing an entire class of data management operations from your program regardless of the language's memory architecture. It's a general speed-optimizing programming style that is irrelevant to manual vs automatic GC. Relative performance in "real systems" written for speed would be a manual memory management language without using malloc/free, vs GC language without using allocation. However, the more interesting case is comparing real systems which do perform runtime allocation; it's highly dependent on the particular program's characteristics, but GC systems can be both a lot faster and simpler architecturally.

pcwalton 11y ago
While you're right in theory, it's typically much less feasible to avoid heap allocations in garbage-collected languages. Systems programmers typically manually promote heap allocations to stack allocations in ways that common escape analysis algorithms cannot prove safe (for example, those involving higher order functions).
moonchrome 11y ago
>However, this is true with garbage collected languages as well. In theory - in practice trying to avoid GC in managed languages is like putting on a straightjacket, eg. JVM doesn't even have value types, and higher level languages - just forget about it :D The closest I realistically got to this is C# and even then there are all sort of caveats because even if your code doesn't allocate it's a standard pattern to not care about allocation and stuff allocates all over the place and there are no tools to figure out what allocates and what doesn't from code so you just have to assume everything does unless you wrote it or read/profiled it.
- pjmlp 11y ago
  Oberon, Oberon-2, Component Pascal, Modula-3, D, Eiffel all provide C++ like value types. Arrays, records, objects can be stored on the global segment, stack or heap. So they stress the GC as much as new/malloc stress the C/C++ memory manager.
Ded7xSEoPKYNsDd 11y ago
> "Properly engineered" probably isn't the right term. C/C++ code written for speed would not perform heap allocation in its main processing. However, this is true with garbage collected languages as well. Not just code written for speed. Stack allocation is easier. There's not much that can go wrong. Heap allocations on the other hand you have to be careful not to leak or free multiple times or free a wrong pointer. So after you've debugged one too many of these bugs, you learn to avoid heap allocations where possible just to make your own life easier. (This is my experience with C, I don't have enough experience with C++ to know whether it sufficiently takes care of some of that complexity to the point where heap allocation becomes as easy as stack allocation.)

pcwalton 11y ago

While you're right in theory, it's typically much less feasible to avoid heap allocations in garbage-collected languages. Systems programmers typically manually promote heap allocations to stack allocations in ways that common escape analysis algorithms cannot prove safe (for example, those involving higher order functions).

moonchrome 11y ago

>However, this is true with garbage collected languages as well. In theory - in practice trying to avoid GC in managed languages is like putting on a straightjacket, eg. JVM doesn't even have value types, and higher level languages - just forget about it :D The closest I realistically got to this is C# and even then there are all sort of caveats because even if your code doesn't allocate it's a standard pattern to not care about allocation and stuff allocates all over the place and there are no tools to figure out what allocates and what doesn't from code so you just have to assume everything does unless you wrote it or read/profiled it.

pjmlp 11y ago
Oberon, Oberon-2, Component Pascal, Modula-3, D, Eiffel all provide C++ like value types. Arrays, records, objects can be stored on the global segment, stack or heap. So they stress the GC as much as new/malloc stress the C/C++ memory manager.

Ded7xSEoPKYNsDd 11y ago

> "Properly engineered" probably isn't the right term. C/C++ code written for speed would not perform heap allocation in its main processing. However, this is true with garbage collected languages as well. Not just code written for speed. Stack allocation is easier. There's not much that can go wrong. Heap allocations on the other hand you have to be careful not to leak or free multiple times or free a wrong pointer. So after you've debugged one too many of these bugs, you learn to avoid heap allocations where possible just to make your own life easier. (This is my experience with C, I don't have enough experience with C++ to know whether it sufficiently takes care of some of that complexity to the point where heap allocation becomes as easy as stack allocation.)