4 ms·

It's not unusual in completely terrible code. The difference is if the memory management is manual, you have the ability to clean it up and reduce that overhea

by jblow 10y ago

It's not unusual in completely terrible code. The difference is if the memory management is manual, you have the ability to clean it up and reduce that overhead toward 0%. If it's a system-enforced GC, you are limited in what you can do.

kasey_junk 10y ago
In the code I write where it matters the issue is allocation & deallocation time. Thus you don't do those things on the hot path in either gc'd or manual memory management environments. Given that the overhead become 0 in either. Is it sometimes harder to write zero alloc code in GC'd languages? Sure but its not impossible. In Java for instance the difference in performance compared to C++ comes from memory layout ability not memory management.
- pjmlp 10y ago
  > In Java for instance the difference in performance compared to C++ comes from memory layout ability not memory management. We need more modern languages with AOT compilation, ability to allocate on the stack and use value types. I like C++ and have spent quite a few years using it, before settling on memory safe languages for my work. Many C++ presentations seem to forget on purpose that there are memory safe programming languages, which offer similar capabilities for controlling memory layouts, thus presenting the language as the only capable of doing it. Modula-3 is an example, or Swift and D for something more actual.
  - CyberDildonics 10y ago
    The reality is that there aren't any straight replacements though since C++ has such mature tools, move semantics take away significant amounts of memory management pain, D without a gc is still exotic, and rust is still in its early stages.
    - pjmlp 10y ago
      It is a matter of which market is relevant for a developer. There are many use cases where C++ is still used where the use case at hand actually didn't any a real need for it. For example, on my area of work, C++ has been out of the picture since around 2006. We only use it when Java or .NET need an helping hand, which happens very seldom. On the mobile OSes for example, C++ is only relevant as possible language to write portable code across platforms, but not so much for those that decide to focus on just one. There Swift, Java and C# are much better options. For those in HPC, languages like Chapel and X10 are gaining adepts. Also as an C++ early adopter (1993) I remember being told by C developers something similar to what you are saying in regards to tool maturity. Now around 30 years later, their compilers are written in C++.
      - CyberDildonics 10y ago
        I'm not trying to claim C++ is the only language anyone will ever need. I've tried hard to find alternatives but until the D community really goes full force on getting the garbage collection out and starts to care about the tools for the language instead of just the language, it seems like rust will be the only contender (and future C++ and maybe even jai). I wish a language called clay had taken off, it was pretty well put together as a better C.
        pjmlp 10y ago
        Actually I would rather like they would improve the GC to more modern algorithms, instead of the basic one it uses.
        duneroadrunner 10y ago
        SaferCPlusPlus[1]: C++. Memory safe. No GC. Quite fast. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
- psyc 10y ago
  I'll mention a significant case that doesn't have to do with allocation. Large graph-like data structures (lots of small nodes linked by reference) are effectively prohibited entirely by the GC. They make every marking phase take much too long, until whenever time the whole thing gets promoted into the long-lived generation. A mainstream runtime having such an impactful opinion about my data structures (not alloc patterns) is something I just find deeply offensive. Imagine if C++ programs stuttered because you had too many pointers! They could have avoided that whole problem by providing an API like DontCollectThisRoot, but instead they (and a lot of programmers) chose to pretend the GC was good enough to treat like a black box.
  - PDoyle 10y ago
    Huh? Are you talking about a particular GC? Because every object-oriented program I've ever seen could be described as "Large graph-like data structures (lots of small nodes linked by reference)".
    - psyc 10y ago
      Any GC that walks the graph, and isn't mostly concurrent. You will know when the graph becomes complex enough, because thereafter the GC will not let you ignore it. In my experience, as few as several hundred thousand objects can become a problem. Imagine trying to write a responsive 3D modeling app with vertices, edges, and faces all bidirectionally pointing to each other. You the programmer would think very carefully before fully traversing such a data structure (much of the point of having thorough internal references is avoiding doing much traversal!), and yet the runtime helpfully does it for you, automatically, and there's nothing you can do to stop it. https://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector https://samsaffron.com/archive/2011/10/28/in-managed-code-we... http://stackoverflow.com/a/14277068 http://stackoverflow.com/a/14277068
    - weberc2 10y ago
      FWIW, Go has value types, so there's less referencing than in Java, etc. Also worth noting that these are actually used unlike in C# which has a reference-type-first culture.
pjmlp 10y ago
Quite true, but the reality is that since Modula-3, Oberon, Eiffel and others did not get adopted at large by the industry, many got the idea that it isn't possible to have a GC for productivity and still manually manage memory, if really required. So now we are stuck with modern languages having to bring those ideas back to life.
weberc2 10y ago
> completely terrible code. Not everyone is writing games...
KirinDave 10y ago
> If it's a system-enforced GC, you are limited in what you can do. Perhaps I'm misunderstanding, but do many C programmers understand not only the current state of malloc at any given moment in their code but exactly how it works? I think not. A lot of the things you do in C++ to reduce memory management overhead are the same things you can do in Java, C#, and Go to reduce memory management overhead. That effort is neither special nor universal. HLLs often have to be careful about using language features that unexpectedly create garbage, but in terms of actual management and collection it's not like ANY competent modern language is slow at it. People often seem to neglect the fact that Java is still surprisingly fast despite spending lots of time on memory management just because many developers are so insensitive to how things alloc. Modern GC systems can manage allocs as well as deallocs, so with care from the programmer and the runtime authors you can reach the kind of performance people talk about as critical for "embedded systems" (even though in practice SO many things do not deliver on this promise in shipped products!).
- lossolo 10y ago
  Embedded systems in most cases have memory constraints and GC languages are memory hogs. The cost of having GC is that you pay with higher memory usage for doing GC in batches thanks to which you do not have to pay for single deallocations. So this performance advantage cannot be used in embedded space because there is no free memory for it, you would need to GC all the time which would kill the performance.
  - weberc2 10y ago
    > GC languages are memory hogs This is unrelated to GC. > The cost of having GC is that you pay with higher memory usage for doing GC in batches thanks to which you do not have to pay for single deallocations. So this performance advantage cannot be used in embedded space because there is no free memory for it, you would need to GC all the time which would kill the performance. The same is true for C. You don't get to make frequent allocations for free in any language. You have to trade space for performance; in GC-land, the answer is tuning the collector. In Go, this is one knob: the GOGC env var.
  - 10y ago
PDoyle 10y ago
Here we go again. https://news.ycombinator.com/item?id=11422064 https://news.ycombinator.com/item?id=11422064

by jblow 10y ago

kasey_junk 10y ago

In the code I write where it matters the issue is allocation & deallocation time. Thus you don't do those things on the hot path in either gc'd or manual memory management environments. Given that the overhead become 0 in either. Is it sometimes harder to write zero alloc code in GC'd languages? Sure but its not impossible. In Java for instance the difference in performance compared to C++ comes from memory layout ability not memory management.

pjmlp 10y ago
> In Java for instance the difference in performance compared to C++ comes from memory layout ability not memory management. We need more modern languages with AOT compilation, ability to allocate on the stack and use value types. I like C++ and have spent quite a few years using it, before settling on memory safe languages for my work. Many C++ presentations seem to forget on purpose that there are memory safe programming languages, which offer similar capabilities for controlling memory layouts, thus presenting the language as the only capable of doing it. Modula-3 is an example, or Swift and D for something more actual.
- CyberDildonics 10y ago
  The reality is that there aren't any straight replacements though since C++ has such mature tools, move semantics take away significant amounts of memory management pain, D without a gc is still exotic, and rust is still in its early stages.
  - pjmlp 10y ago
    It is a matter of which market is relevant for a developer. There are many use cases where C++ is still used where the use case at hand actually didn't any a real need for it. For example, on my area of work, C++ has been out of the picture since around 2006. We only use it when Java or .NET need an helping hand, which happens very seldom. On the mobile OSes for example, C++ is only relevant as possible language to write portable code across platforms, but not so much for those that decide to focus on just one. There Swift, Java and C# are much better options. For those in HPC, languages like Chapel and X10 are gaining adepts. Also as an C++ early adopter (1993) I remember being told by C developers something similar to what you are saying in regards to tool maturity. Now around 30 years later, their compilers are written in C++.
    - CyberDildonics 10y ago
      I'm not trying to claim C++ is the only language anyone will ever need. I've tried hard to find alternatives but until the D community really goes full force on getting the garbage collection out and starts to care about the tools for the language instead of just the language, it seems like rust will be the only contender (and future C++ and maybe even jai). I wish a language called clay had taken off, it was pretty well put together as a better C.
      - pjmlp 10y ago
        Actually I would rather like they would improve the GC to more modern algorithms, instead of the basic one it uses.
      - duneroadrunner 10y ago
        SaferCPlusPlus[1]: C++. Memory safe. No GC. Quite fast. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
psyc 10y ago
I'll mention a significant case that doesn't have to do with allocation. Large graph-like data structures (lots of small nodes linked by reference) are effectively prohibited entirely by the GC. They make every marking phase take much too long, until whenever time the whole thing gets promoted into the long-lived generation. A mainstream runtime having such an impactful opinion about my data structures (not alloc patterns) is something I just find deeply offensive. Imagine if C++ programs stuttered because you had too many pointers! They could have avoided that whole problem by providing an API like DontCollectThisRoot, but instead they (and a lot of programmers) chose to pretend the GC was good enough to treat like a black box.
- PDoyle 10y ago
  Huh? Are you talking about a particular GC? Because every object-oriented program I've ever seen could be described as "Large graph-like data structures (lots of small nodes linked by reference)".
  - psyc 10y ago
    Any GC that walks the graph, and isn't mostly concurrent. You will know when the graph becomes complex enough, because thereafter the GC will not let you ignore it. In my experience, as few as several hundred thousand objects can become a problem. Imagine trying to write a responsive 3D modeling app with vertices, edges, and faces all bidirectionally pointing to each other. You the programmer would think very carefully before fully traversing such a data structure (much of the point of having thorough internal references is avoiding doing much traversal!), and yet the runtime helpfully does it for you, automatically, and there's nothing you can do to stop it. https://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector https://samsaffron.com/archive/2011/10/28/in-managed-code-we... http://stackoverflow.com/a/14277068 http://stackoverflow.com/a/14277068
  - weberc2 10y ago
    FWIW, Go has value types, so there's less referencing than in Java, etc. Also worth noting that these are actually used unlike in C# which has a reference-type-first culture.

pjmlp 10y ago

Quite true, but the reality is that since Modula-3, Oberon, Eiffel and others did not get adopted at large by the industry, many got the idea that it isn't possible to have a GC for productivity and still manually manage memory, if really required. So now we are stuck with modern languages having to bring those ideas back to life.

weberc2 10y ago

> completely terrible code. Not everyone is writing games...

KirinDave 10y ago

> If it's a system-enforced GC, you are limited in what you can do. Perhaps I'm misunderstanding, but do many C programmers understand not only the current state of malloc at any given moment in their code but exactly how it works? I think not. A lot of the things you do in C++ to reduce memory management overhead are the same things you can do in Java, C#, and Go to reduce memory management overhead. That effort is neither special nor universal. HLLs often have to be careful about using language features that unexpectedly create garbage, but in terms of actual management and collection it's not like ANY competent modern language is slow at it. People often seem to neglect the fact that Java is still surprisingly fast despite spending lots of time on memory management just because many developers are so insensitive to how things alloc. Modern GC systems can manage allocs as well as deallocs, so with care from the programmer and the runtime authors you can reach the kind of performance people talk about as critical for "embedded systems" (even though in practice SO many things do not deliver on this promise in shipped products!).

lossolo 10y ago
Embedded systems in most cases have memory constraints and GC languages are memory hogs. The cost of having GC is that you pay with higher memory usage for doing GC in batches thanks to which you do not have to pay for single deallocations. So this performance advantage cannot be used in embedded space because there is no free memory for it, you would need to GC all the time which would kill the performance.
- weberc2 10y ago
  > GC languages are memory hogs This is unrelated to GC. > The cost of having GC is that you pay with higher memory usage for doing GC in batches thanks to which you do not have to pay for single deallocations. So this performance advantage cannot be used in embedded space because there is no free memory for it, you would need to GC all the time which would kill the performance. The same is true for C. You don't get to make frequent allocations for free in any language. You have to trade space for performance; in GC-land, the answer is tuning the collector. In Go, this is one knob: the GOGC env var.
- 10y ago

PDoyle 10y ago

Here we go again. https://news.ycombinator.com/item?id=11422064 https://news.ycombinator.com/item?id=11422064