4 ms·

Automatic memory management...? "Just use Boost" is not a viable strategy when it adds so much complexity in and of itself. I'm not defending Java, but it's h

Automatic memory management...? "Just use Boost" is not a viable strategy when it adds so much complexity in and of itself. I'm not defending Java, but it's helpful to know what the limits of each tool are.

eropple 13y ago
Automatic memory management (especially with a garbage collector) is antithetical to high performance. I like the JVM (for Scala, mostly; Java-the-language can go screw), but there is nothing there really remotely close to C++ and C, and the garbage collector is a very large part of why.. Rust might horn in on C++'s bailiwick, but until then, it's gonna be a while. I strongly disagree that Boost really adds "so much complexity"--and, by the way, shared_ptr and friends are in C++11, and by extension within the standard library. So you don't even need this, unless your goal is to target extremely old platforms. But honestly, if you seriously need shared_ptr, your code design is probably just Not Very Good.
- sillysaurus2 13y ago
  Automatic memory management (especially with a garbage collector) is antithetical to high performance. The LMAX Disruptor pattern would like to have a word with you. http://lmax-exchange.github.io/disruptor/ http://lmax-exchange.github.io/disruptor/ http://martinfowler.com/articles/lmax.html http://martinfowler.com/articles/lmax.html http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work http://stackoverflow.com/questions/6559308/how-does-lmaxs-di... I'm not just namechecking the Disruptor pattern. I have extensive experience with it. It's about 10% slower than what could be achieved with C -- which is to say, the benefits of not having to program in C far outweigh the 10% loss of performance. And its performance is almost always far higher than what's needed, i.e. the bottlenecks are elsewhere. I strongly disagree that Boost really adds "so much complexity" We'll have to agree to disagree, I think. Importing Boost is often a sign that something is awry with the design goals of the project. Either the choice of language is wrong, or the project is too ambitious. Though there are some aspects of Boost that are pretty good, such as its unit testing framework. if you seriously need shared_ptr, your code design is probably just Not Very Good. This I fully agree with.
  - haberman 13y ago
    > It's about 10% slower than what could be achieved with C What does that even mean? Are you saying that you have a proof of the theoretically fastest C program that would implement the same functionality and it's 10% slower than that? Does the C you're comparing it against use the Disruptor pattern too? Or is this just a comparison against a naive, single-threaded C program? How does that number vary with the overall heap size of the program? Numbers like this get thrown around that strike me as incredibly dubious.
- pjmlp 13y ago
  Good luck doing manual memory management in whatever language (C, Pascal, C++, ...) with distributed teams, using developers of disparate skill levels. Hunting for memory leaks and pointers gone berserk will become someone's full time job. I like C++, but don't miss using it in enterprise projects.
- pron 13y ago
  Sigh. This again? A good garbage collector will always reach a higher throughput than "manual" dynamic allocation/deallocation in C/C++. Pauses are a different matter, and can impact latency; in cases where latency is crucial, Java programs either resort to manual memory management or use a commercial low-latency GC. If you're comparing the JVM's GCed heap with some specific, user-managed allocation scheme, then know that the latter can be done (and is often done) in Java too.
  - alpatters 13y ago
    C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency. You shouldn't really use the term "always" either. You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
    - pron 13y ago
      > C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Modern machines have, I don't know, say, 64GB RAM? How much of that can you use for thread stacks? 1GB tops? Modern applications work with really big heaps. Stack allocation is irrelevant for most of what the application is doing. > Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency. Yeah, it seems that way, but it turns out that it isn't. Previous attempts to allocate Java objects on the stack showed little or no improvements. A heap allocation in Java is a pointer bump, and deallocation of a short-lived object is free (Well, this is not quite true, because many allocations will trigger a young-generation collection which, in the JDK's GCs – though not in some commercial ones – takes linear time in the size of surviving objects) > You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead. You have the same option in Java, too, and it's pretty much the same amount of work.
      - 13y ago

eropple 13y ago

Automatic memory management (especially with a garbage collector) is antithetical to high performance. I like the JVM (for Scala, mostly; Java-the-language can go screw), but there is nothing there really remotely close to C++ and C, and the garbage collector is a very large part of why.. Rust might horn in on C++'s bailiwick, but until then, it's gonna be a while. I strongly disagree that Boost really adds "so much complexity"--and, by the way, shared_ptr and friends are in C++11, and by extension within the standard library. So you don't even need this, unless your goal is to target extremely old platforms. But honestly, if you seriously need shared_ptr, your code design is probably just Not Very Good.

sillysaurus2 13y ago
Automatic memory management (especially with a garbage collector) is antithetical to high performance. The LMAX Disruptor pattern would like to have a word with you. http://lmax-exchange.github.io/disruptor/ http://lmax-exchange.github.io/disruptor/ http://martinfowler.com/articles/lmax.html http://martinfowler.com/articles/lmax.html http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work http://stackoverflow.com/questions/6559308/how-does-lmaxs-di... I'm not just namechecking the Disruptor pattern. I have extensive experience with it. It's about 10% slower than what could be achieved with C -- which is to say, the benefits of not having to program in C far outweigh the 10% loss of performance. And its performance is almost always far higher than what's needed, i.e. the bottlenecks are elsewhere. I strongly disagree that Boost really adds "so much complexity" We'll have to agree to disagree, I think. Importing Boost is often a sign that something is awry with the design goals of the project. Either the choice of language is wrong, or the project is too ambitious. Though there are some aspects of Boost that are pretty good, such as its unit testing framework. if you seriously need shared_ptr, your code design is probably just Not Very Good. This I fully agree with.
- haberman 13y ago
  > It's about 10% slower than what could be achieved with C What does that even mean? Are you saying that you have a proof of the theoretically fastest C program that would implement the same functionality and it's 10% slower than that? Does the C you're comparing it against use the Disruptor pattern too? Or is this just a comparison against a naive, single-threaded C program? How does that number vary with the overall heap size of the program? Numbers like this get thrown around that strike me as incredibly dubious.
pjmlp 13y ago
Good luck doing manual memory management in whatever language (C, Pascal, C++, ...) with distributed teams, using developers of disparate skill levels. Hunting for memory leaks and pointers gone berserk will become someone's full time job. I like C++, but don't miss using it in enterprise projects.
pron 13y ago
Sigh. This again? A good garbage collector will always reach a higher throughput than "manual" dynamic allocation/deallocation in C/C++. Pauses are a different matter, and can impact latency; in cases where latency is crucial, Java programs either resort to manual memory management or use a commercial low-latency GC. If you're comparing the JVM's GCed heap with some specific, user-managed allocation scheme, then know that the latter can be done (and is often done) in Java too.
- alpatters 13y ago
  C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency. You shouldn't really use the term "always" either. You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
  - pron 13y ago
    > C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Modern machines have, I don't know, say, 64GB RAM? How much of that can you use for thread stacks? 1GB tops? Modern applications work with really big heaps. Stack allocation is irrelevant for most of what the application is doing. > Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency. Yeah, it seems that way, but it turns out that it isn't. Previous attempts to allocate Java objects on the stack showed little or no improvements. A heap allocation in Java is a pointer bump, and deallocation of a short-lived object is free (Well, this is not quite true, because many allocations will trigger a young-generation collection which, in the JDK's GCs – though not in some commercial ones – takes linear time in the size of surviving objects) > You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead. You have the same option in Java, too, and it's pretty much the same amount of work.
    - 13y ago