4 ms·

Ahhh, He started talking about needing concurrency to be able to make use of multicode CPUs, and his solution is C++ ??? The number of cores is multiplying wit

Ahhh, He started talking about needing concurrency to be able to make use of multicode CPUs, and his solution is C++ ??? The number of cores is multiplying with Moore's Law. It doesn't take many multiplications before a language able to easily make use of those multicores efficiently will blow past C++ in performance.

angersock 15y ago
So, before you rush off to dismiss C++, note a very important thing: With reference-counted smart pointers, you can guarantee that objects immediately go away once they leave scope, and that you can pass them around between threads without worrying too much about a thread forgetting to delete them. No other language has such easy support for doing something like that without relying on a background memory-management mechanism (at least that I'm aware of--I'd like to hear about it if you know one!).
- mrich 15y ago
  Objective-C with ARC comes pretty close.
  - angersock 15y ago
    Out of curiosity, when does the GC happen there? Does Objective-C have strict enforcement of destruction-on-scope exiting? (not a Objective-C dev, so don't know)
    - ootachi 15y ago
      Yes, Objective-C will reclaim your retained objects promptly (unless you use the deprecated Objective-C garbage collection, which few do and never worked on iOS). The exception is the autorelease pool, which gets dumped at the end of every turn of the event loop. You can promote or demote objects from the autorelease pool at will. Anyway, the biggest problems with Obj-C memory management are (a) you can't allocate objects on the stack, so you're forced into using the autorelease pool for stuff, and (b) you can promote or demote objects from the autorelease pool at will, which means that even the autorelease pool has to malloc, thus you don't get the nice benefits of super-cheap bump allocation that C++ arenas (or a generational GC's nursery) buy you.
      - angersock 15y ago
        I'm still a little puzzled by the phrase "promptly"--you mean as soon as it goes out of scope, right? Like, immediately? Anyways, thank you for the information!
        ootachi 15y ago
        Right, as soon as it goes out of scope. (Or when you call release to drop the last reference on it, if you aren't using ARC.)
- ootachi 15y ago
  Well, you have to make sure that you use atomic reference counting in this case. Using regular reference counting will lead to subtle and hard-to-diagnose bugs. Also, to answer your query, Rust uses unique pointers (the equivalent of std::unique_ptr in C++0x) for inter-thread communication. When the unique pointer goes out of scope, its memory is immediately freed (since it was the only owner of the data). And since the data has only one owner, it's data-race-free.
  - angersock 15y ago
    Yeah, one of the first things we fixed in our smart pointer implementation was to use atomic ops for the ref counters. This had the unfortunate side effect of excluding the smart pointer classes from our STL replacement (as it introduces a dependency on our low-level ops library), but in projects using both all is well. Cool on Rust, though! Thanks for the info!
- pmjordan 15y ago
  Reference counting is nothing new. Visual Basic used it before the transition to .NET. Python uses it, if I remember correctly (with occasional GC to avoid leaks due to cycles). There are probably countless other examples. Reference counting is also not even that great for shared memory multithreading. The (atomic) increment/decrement operations typically cause lots of cache invalidation, so you'll get a slowdown even for immutable objects.
  - angersock 15y ago
    Ref counting by itself is nothing new, agreed. The fact that I can reliably say when things go out of scope in C++, though, combined with ref counting, is quite handy. Interesting point about the cache invalidation, though. I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops.
    - pmjordan 15y ago
      I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops. They already put a lot of effort into making this stuff as efficient as possible - the fact that Intel is going in the direction of hardware transactional memory indicates to me that they don't think the bus locking/cache snooping approach scales, and I can't say I'm surprised.
  - ootachi 15y ago
    Yeah, atomic RC hurts a lot (5x-10x slower, based on the measurements I've seen -- Hans Boehm of Boehm GC fame did a presentation on this that you can find if you're interested). (This is a problem with Objective-C reference counting -- they use atomic ops for all reference counting I believe.) There's some work on mitigating its cost with per-thread reference counts arranged in a tree or whatever, but it's still tough. The alternatives are either (a) avoiding shared state; (b) strong lifetime management such that you make sure one parent thread owns all of the data that its child threads are going to use; (c) concurrent GC; (d) pretending it's not a problem like Go does and doing stop-the-world GC.
mrich 15y ago
Modern C++ code is multithreaded, threading is now finally part of the standard. While C++ is showing its age, and the refusal to cut any old features at all sure is no advantage, it is still the language to beat for performance and especially memory usage.
- rbanffy 15y ago
  The problem is not the ability to start threads - it's enabling the programmer to express the problems in concurrent form.

angersock 15y ago

So, before you rush off to dismiss C++, note a very important thing: With reference-counted smart pointers, you can guarantee that objects immediately go away once they leave scope, and that you can pass them around between threads without worrying too much about a thread forgetting to delete them. No other language has such easy support for doing something like that without relying on a background memory-management mechanism (at least that I'm aware of--I'd like to hear about it if you know one!).

mrich 15y ago
Objective-C with ARC comes pretty close.
- angersock 15y ago
  Out of curiosity, when does the GC happen there? Does Objective-C have strict enforcement of destruction-on-scope exiting? (not a Objective-C dev, so don't know)
  - ootachi 15y ago
    Yes, Objective-C will reclaim your retained objects promptly (unless you use the deprecated Objective-C garbage collection, which few do and never worked on iOS). The exception is the autorelease pool, which gets dumped at the end of every turn of the event loop. You can promote or demote objects from the autorelease pool at will. Anyway, the biggest problems with Obj-C memory management are (a) you can't allocate objects on the stack, so you're forced into using the autorelease pool for stuff, and (b) you can promote or demote objects from the autorelease pool at will, which means that even the autorelease pool has to malloc, thus you don't get the nice benefits of super-cheap bump allocation that C++ arenas (or a generational GC's nursery) buy you.
    - angersock 15y ago
      I'm still a little puzzled by the phrase "promptly"--you mean as soon as it goes out of scope, right? Like, immediately? Anyways, thank you for the information!
      - ootachi 15y ago
        Right, as soon as it goes out of scope. (Or when you call release to drop the last reference on it, if you aren't using ARC.)
ootachi 15y ago
Well, you have to make sure that you use atomic reference counting in this case. Using regular reference counting will lead to subtle and hard-to-diagnose bugs. Also, to answer your query, Rust uses unique pointers (the equivalent of std::unique_ptr in C++0x) for inter-thread communication. When the unique pointer goes out of scope, its memory is immediately freed (since it was the only owner of the data). And since the data has only one owner, it's data-race-free.
- angersock 15y ago
  Yeah, one of the first things we fixed in our smart pointer implementation was to use atomic ops for the ref counters. This had the unfortunate side effect of excluding the smart pointer classes from our STL replacement (as it introduces a dependency on our low-level ops library), but in projects using both all is well. Cool on Rust, though! Thanks for the info!
pmjordan 15y ago
Reference counting is nothing new. Visual Basic used it before the transition to .NET. Python uses it, if I remember correctly (with occasional GC to avoid leaks due to cycles). There are probably countless other examples. Reference counting is also not even that great for shared memory multithreading. The (atomic) increment/decrement operations typically cause lots of cache invalidation, so you'll get a slowdown even for immutable objects.
- angersock 15y ago
  Ref counting by itself is nothing new, agreed. The fact that I can reliably say when things go out of scope in C++, though, combined with ref counting, is quite handy. Interesting point about the cache invalidation, though. I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops.
  - pmjordan 15y ago
    I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops. They already put a lot of effort into making this stuff as efficient as possible - the fact that Intel is going in the direction of hardware transactional memory indicates to me that they don't think the bus locking/cache snooping approach scales, and I can't say I'm surprised.
- ootachi 15y ago
  Yeah, atomic RC hurts a lot (5x-10x slower, based on the measurements I've seen -- Hans Boehm of Boehm GC fame did a presentation on this that you can find if you're interested). (This is a problem with Objective-C reference counting -- they use atomic ops for all reference counting I believe.) There's some work on mitigating its cost with per-thread reference counts arranged in a tree or whatever, but it's still tough. The alternatives are either (a) avoiding shared state; (b) strong lifetime management such that you make sure one parent thread owns all of the data that its child threads are going to use; (c) concurrent GC; (d) pretending it's not a problem like Go does and doing stop-the-world GC.

mrich 15y ago

Modern C++ code is multithreaded, threading is now finally part of the standard. While C++ is showing its age, and the refusal to cut any old features at all sure is no advantage, it is still the language to beat for performance and especially memory usage.

rbanffy 15y ago
The problem is not the ability to start threads - it's enabling the programmer to express the problems in concurrent form.