Hacker News Reader

Comment by pkolaczk | Hacker News Reader

It is sometimes handy, but generally compared to GC it is slow and incurs lots of contention in multithreaded programs.

Imagine you return a reference-counted pointer from a function. Then every call to this function is a lock/unlock and CPU cache synchronization. And if the pointed object is shared between threads (even for read-only access) this might lead to lot of contended locks/unlocks, which is extremely costly.

View on HN

The synchronization you mention is really rare, it only happens when you make a copy (not a move!) of a std::shared_ptr.

If you have a std::shared_ptr<X>, then most of the time you will be passing around "X &" or "std::shared_ptr<X> &" and no copies will happen.

Do you have an example of why a function would be returning a std::shared_ptr<X> by value that wasn't a move?

To return a shared_ptr you first had to create it. So even if it optimizes the move, it doesn't optimize away the creation of the pointer and its destruction.

As of using naked references, you're right, but if you can use naked references, why ever use shared_ptr? Naked references are fine when you know the lifetime of the object.

Don't get me wrong - shared pointers are useful in many scenarios, but they are not a general replacement for GC.

BTW: Here is the post of someone who thought he can use shared_ptr as a poor-man's GC: http://stackoverflow.com/questions/2502394/the-cost-of-passi...

shared_ptr took 17% of time. This is far beyond what GC takes even in a very memory heavy Java application (typically GC stays below 1% overhead).

I'm not saying you shouldn't use shared_ptr at all, but only: be careful.

Novices also sometimes erroneously pass std::vector by value, that doesn't mean std::vector is slow. Maybe you did not read the entire post before linking it. The conclusion was he changed his code to pass by reference and 17.77% became .27%.

Thanks for pointing that out, I had heard horror stories before and was willing to take 17.77% at face value!

You can use naked references because most functions aren't acquiring ownership of a shared_ptr.

I always hear about how use of mutexes is costly but i never actually encountered a significant performance hit from using synchronization. Unless, of course, you have like 10 threads frequently accessing the same memory, which is more a design issue.

Uncontended interlocked operation is typically about 100-300 CPU cycles. Uncontended mutex is about 30x-50x that. If there is contention, multiply everything by another 100x. Additionally these instructions impact not only the calling thread but also other threads by forcing cache synchronization.

Therefore a relatively simple operation like pointer assignment can be one cycle when using GC and a hundred to several thousands cycles when using refcounting. Sometimes you can ignore this overhead, sometimes not - depends on how often you do that.

http://software.intel.com/en-us/articles/choosing-between-sy...

On what CPU? on my i7s it's much faster. on the order of 50 cycles for a uncontended mutex lock and release i think. I can dig out the values if anyone cares.

Reply on news.ycombinator.com