4 ms·

Worth pointing out, the resource management strategy isn't even necessarily a net positive for performance. In typical GC'd languages you have a much richer des

Worth pointing out, the resource management strategy isn't even necessarily a net positive for performance. In typical GC'd languages you have a much richer design space for your memory system. You can move stuff around, you have flexibility as to when you do collection, you often have allocation as a built-in primitive, which means the compiler knows about it and can help optimize. The end result is that good GC-based memory systems tend to perform better than malloc/free style APIs (with the call to free() possibly being implicit). to get good performance in C/C++/Rust, the programmer needs to be concientious about allocation. You have more control, but also more responsibility. In OCaml, allocation is bumping a pointer -- go nuts.

dpc_pw 9y ago
> The end result is that good GC-based memory systems tend to perform better than malloc/free style APIs Citation needed. GCs promise wonders, and yet in practice they are going to eat your memory, trash caches, and slow everything down. Performance benefits are typical "in some applications, in some use cases, etc." not "tend to"
- zenhack 9y ago
  Okay, yeah, I should temper that statement. This stuff is super hard to actually study rigorously, and I certainly don't have a reference to support as broad and vague a claim as "tend to perform better." And of course "perform" is a very muilti-dimentional thing, not a single value. The truth of the matter is that any generic memory management strategy is going to fall on it's face in certain scenarios; most folks have seen first hand the raii failure mode where some application takes forever just to exit, because it's pointlessly calling god-knows how many destructors. It's late, and I should generally try to be more clear with myself about what my point is before I post. The thing in there that I think is more salient is, with manual memory management you're opting into control, not magic everything-is-faster-now. I don't think the op was suggesting it, but people often act like using a lower level language is going to always make things faster, ans it just isn't true. Idiomatic, decently performing OCaml is going to make for some very slow Rust.
- pjmlp 9y ago
  Depends on the GC implementation, not all of them "eat your memory, trash caches, and slow everything down" the same way. And even those that do, if they do it within the time and memory budget bounds for the task goals, then that is still a win. I don't care that manually managed memory would solve the task with 10ms and 20KB, the GC with 100ms and 200KB, if my budget is 1s and 1MB.
- thesz 9y ago
  You asked for citation, here it is: https://www.sciencedirect.com/science/article/pii/002001908790175X https://www.sciencedirect.com/science/article/pii/0020019087... Garbage collection can be faster than stack allocation when your live set is much smaller than memory.
- saurik 9y ago
  > Citation needed. Oh come on: this is a well-known property of garbage collectors and should have been covered in an entry-level CS class. Did you even try to find this before pulling out the "citation needed" trope? Hacker News needs an auto-responses to any comment that has that phrase in it with "have you tried Google yet?" :/. With just ten seconds of Google searching (so surely less time than it likely took you to type your "citation needed") I was able to find a meta-reference (a Stack Overflow answer with links to papers looking at this result). The results were "similar or up to 4% faster" and "much faster with lots of ram". https://stackoverflow.com/questions/755878/any-hard-data-on-gc-vs-explicit-memory-management-performance https://stackoverflow.com/questions/755878/any-hard-data-on-... (At least one of those links is dead, but it is to the same paper that thesz linked to in a sibling to this comment... a comment which provided a citation and which someone downvoted, because people care more about opinion than actually finding citations. I upvoted his comment back to being rendered in black text :/.) What is so strange about this being controversial is that it is truly an obvious result: a real heap allocation is really really slow, and a copying collector never has to allocate anything (it just bumps a pointer). So only when you have memory pressure does it eventually prune objects, and until then it runs lightning fast: faster than the malloc/free code could possibly dream of. The advantage of affine types (as in Rust) isn't actually that it is avoiding GC: it is that it makes it possible to avoid allocation itself by making it safe to allocate things on the stack (where you get the speed of bumping a pointer again instead of the painfully slow malloc). That is the kind of analysis that is often attempted by languages like Java ("escape analysis"), but is only available in limited circumstances.
  - Veedrac 9y ago
    Thinking GC is slow is an easily mistake because GC encourages languages to allocate pathologically, which is slow.
  - dpc_pw 9y ago
    > Oh come on: this is a well-known property of garbage collectors and should have been covered in an entry-level CS class. There's plenty of BS tought in academia. In CS that would include love for modeling tools (I had classes about IBM Rational tools, bleh), OOP and other forms of sophisticated complexity. The practicioners tend to dislike GCs, but again it's not a good argument. > a real heap allocation is really really slow There is nothing preventing a heap allocation to be almost as fast, at the cost of memory fragmentation/overutilization and/or slower deallocation. And that's where the whole tradeoff is. Memory allocation has to track data explicitily, GC tracks data implicitly. Typically this tradeoff is expressed in a memory over-consmpation of GC to amortize the GC deallocation slowness. And it's all dandy on paper, because the argument is "oh, just take more memory and you're fast again". Which is not such an easy thing to do. Such memory could be used as a IO caches or to run other processes. And over and over companies rewrite their memory-hogging GC-ing services into explicit-memory allocation languages and they run faster and what's more important, utilize less memory and thus make the whole system faster. They can run on much smaller VM instances etc. So the whole "GC is as fast or even faster" is dubious in general sense, IMO. And most of the papers trying to prove it is of form "in this specific circumstances GC can run the same or even outperform mangaged memory lanagues".
catnaroek 9y ago
As I said before, resource management is first and foremost a matter of correctness, so performance is neither here nor there. While you don't need manual resource management for data structures containing values, you do need it for various types of handles (files, network connections, you name it), which a GC cannot guarantee it will collect at the right moment. There is no reason why you couldn't have GC when it makes sense, and deterministic reclamation where it is required.
- pjmlp 9y ago
  > There is no reason why you couldn't have GC when it makes sense, and deterministic reclamation where it is required. Which is actually available in quite a few GC enabled languages. I think lack of exposure to multiple programming languages has created this urban myth that there is only one way of doing resource management in languages with a GC. That is what happens when professional schools adopt "one language to rule them all" teaching.
  - catnaroek 9y ago
    > Which is actually available in quite a few GC enabled languages. In existing implementations, not with Rust's static safety guarantees about dynamically allocated resources, sorry. “Just provide some way to disable the garbage collector” raises some obvious (at least to me) questions that are nevertheless not addressed by the alternatives you usually propose: (0) When does it make sense to disable the GC? (1) How do we know we are using resources correctly by ourselves? (2) How do we know we are cleaning up resources correctly by ourselves? (3) How would you rigorously prove all of the above? (Yes, unlike most other programmers, I do prove my programs correct.)
    - pjmlp 9y ago
      I have not written anywhere “Just provide some way to disable the garbage collector”, rather that they offer other ways of managing resources. In Modula-3 or D, as possible examples, a solution might be destructors or scope attributes. The only way to actually be 100% safe would be if everyone would be programming with formal logic, which still requires a lot of research to make it approachable by the average developer.

dpc_pw 9y ago

> The end result is that good GC-based memory systems tend to perform better than malloc/free style APIs Citation needed. GCs promise wonders, and yet in practice they are going to eat your memory, trash caches, and slow everything down. Performance benefits are typical "in some applications, in some use cases, etc." not "tend to"

zenhack 9y ago
Okay, yeah, I should temper that statement. This stuff is super hard to actually study rigorously, and I certainly don't have a reference to support as broad and vague a claim as "tend to perform better." And of course "perform" is a very muilti-dimentional thing, not a single value. The truth of the matter is that any generic memory management strategy is going to fall on it's face in certain scenarios; most folks have seen first hand the raii failure mode where some application takes forever just to exit, because it's pointlessly calling god-knows how many destructors. It's late, and I should generally try to be more clear with myself about what my point is before I post. The thing in there that I think is more salient is, with manual memory management you're opting into control, not magic everything-is-faster-now. I don't think the op was suggesting it, but people often act like using a lower level language is going to always make things faster, ans it just isn't true. Idiomatic, decently performing OCaml is going to make for some very slow Rust.
pjmlp 9y ago
Depends on the GC implementation, not all of them "eat your memory, trash caches, and slow everything down" the same way. And even those that do, if they do it within the time and memory budget bounds for the task goals, then that is still a win. I don't care that manually managed memory would solve the task with 10ms and 20KB, the GC with 100ms and 200KB, if my budget is 1s and 1MB.
thesz 9y ago
You asked for citation, here it is: https://www.sciencedirect.com/science/article/pii/002001908790175X https://www.sciencedirect.com/science/article/pii/0020019087... Garbage collection can be faster than stack allocation when your live set is much smaller than memory.
saurik 9y ago
> Citation needed. Oh come on: this is a well-known property of garbage collectors and should have been covered in an entry-level CS class. Did you even try to find this before pulling out the "citation needed" trope? Hacker News needs an auto-responses to any comment that has that phrase in it with "have you tried Google yet?" :/. With just ten seconds of Google searching (so surely less time than it likely took you to type your "citation needed") I was able to find a meta-reference (a Stack Overflow answer with links to papers looking at this result). The results were "similar or up to 4% faster" and "much faster with lots of ram". https://stackoverflow.com/questions/755878/any-hard-data-on-gc-vs-explicit-memory-management-performance https://stackoverflow.com/questions/755878/any-hard-data-on-... (At least one of those links is dead, but it is to the same paper that thesz linked to in a sibling to this comment... a comment which provided a citation and which someone downvoted, because people care more about opinion than actually finding citations. I upvoted his comment back to being rendered in black text :/.) What is so strange about this being controversial is that it is truly an obvious result: a real heap allocation is really really slow, and a copying collector never has to allocate anything (it just bumps a pointer). So only when you have memory pressure does it eventually prune objects, and until then it runs lightning fast: faster than the malloc/free code could possibly dream of. The advantage of affine types (as in Rust) isn't actually that it is avoiding GC: it is that it makes it possible to avoid allocation itself by making it safe to allocate things on the stack (where you get the speed of bumping a pointer again instead of the painfully slow malloc). That is the kind of analysis that is often attempted by languages like Java ("escape analysis"), but is only available in limited circumstances.
- Veedrac 9y ago
  Thinking GC is slow is an easily mistake because GC encourages languages to allocate pathologically, which is slow.
- dpc_pw 9y ago
  > Oh come on: this is a well-known property of garbage collectors and should have been covered in an entry-level CS class. There's plenty of BS tought in academia. In CS that would include love for modeling tools (I had classes about IBM Rational tools, bleh), OOP and other forms of sophisticated complexity. The practicioners tend to dislike GCs, but again it's not a good argument. > a real heap allocation is really really slow There is nothing preventing a heap allocation to be almost as fast, at the cost of memory fragmentation/overutilization and/or slower deallocation. And that's where the whole tradeoff is. Memory allocation has to track data explicitily, GC tracks data implicitly. Typically this tradeoff is expressed in a memory over-consmpation of GC to amortize the GC deallocation slowness. And it's all dandy on paper, because the argument is "oh, just take more memory and you're fast again". Which is not such an easy thing to do. Such memory could be used as a IO caches or to run other processes. And over and over companies rewrite their memory-hogging GC-ing services into explicit-memory allocation languages and they run faster and what's more important, utilize less memory and thus make the whole system faster. They can run on much smaller VM instances etc. So the whole "GC is as fast or even faster" is dubious in general sense, IMO. And most of the papers trying to prove it is of form "in this specific circumstances GC can run the same or even outperform mangaged memory lanagues".

catnaroek 9y ago

As I said before, resource management is first and foremost a matter of correctness, so performance is neither here nor there. While you don't need manual resource management for data structures containing values, you do need it for various types of handles (files, network connections, you name it), which a GC cannot guarantee it will collect at the right moment. There is no reason why you couldn't have GC when it makes sense, and deterministic reclamation where it is required.

pjmlp 9y ago
> There is no reason why you couldn't have GC when it makes sense, and deterministic reclamation where it is required. Which is actually available in quite a few GC enabled languages. I think lack of exposure to multiple programming languages has created this urban myth that there is only one way of doing resource management in languages with a GC. That is what happens when professional schools adopt "one language to rule them all" teaching.
- catnaroek 9y ago
  > Which is actually available in quite a few GC enabled languages. In existing implementations, not with Rust's static safety guarantees about dynamically allocated resources, sorry. “Just provide some way to disable the garbage collector” raises some obvious (at least to me) questions that are nevertheless not addressed by the alternatives you usually propose: (0) When does it make sense to disable the GC? (1) How do we know we are using resources correctly by ourselves? (2) How do we know we are cleaning up resources correctly by ourselves? (3) How would you rigorously prove all of the above? (Yes, unlike most other programmers, I do prove my programs correct.)
  - pjmlp 9y ago
    I have not written anywhere “Just provide some way to disable the garbage collector”, rather that they offer other ways of managing resources. In Modula-3 or D, as possible examples, a solution might be destructors or scope attributes. The only way to actually be 100% safe would be if everyone would be programming with formal logic, which still requires a lot of research to make it approachable by the average developer.