[Interest] CppCon Just Ended (next year will be 20-25 Sep 2015)

[Till Oliver Knoll]

Am 14.09.2014 um 18:43 schrieb "charleyb123 ." <charleyb123 at gmail.com>:

> ...
> WOW AGAIN for a great conference.  Really heavy-hitters there, with information I don't know is available elsewhere.  For example:

Thank you a lot for that nice overview of the talks and discussions at the CppCon 2014, I read it with great interest!

Off course I'd have many questions and would love to hear more about each topic :)

But I just picked up the following:

> 
> *- Facebook (Andrei Alexandrescu) "cheats" with "stealing bits" from their implementation of a "shared-pointer" to "steal-bits" for the "object-count", with the understanding that the count rarely goes above "4".  Correctness is sacrificed to increase performance 0.4%, which is a "huge win" for server load and electricity (saves $millions a month).  "Leak, Log, and Leave" is what they do for the uncommon correctness failure-case.

So my first thought is that since they observed that "the reference count rarely goes above 4" that they restrict their counters to N bits only, where N < 8 ("Byte").

So let's say they'd use only 4 bits for their reference counters in their "smart pointer" implementation. If you placed all the reference counters into an "external array structure", "array of char" (which would - somehow - be "globally accessible" without storing an extra pointer to it in each smart pointer instance), then you could place two reference counters into a char, hence reducing the memory usage by factor 2 (compared to reference counters implemented as "char" (byte) only (*)).

So you save a little (how much?) memory. Let's be generous: let's say a typical application of theirs would consume 20% less RAM with such "memory optimised counters". Saving a few GB of RAM on their servers could probably indeed save you some bucks on the electricity bill. 


But off course you'd need to keep track of reference counters which go to 0 (-> "re-use") - or you just let the "array of compressed reference counters" grow.

But then the biggest matter is off course leaked memory: once such a "4 bit reference counter" gets "saturated", you have to "mark" that smart pointer as "is leaking": there is no way the involved object could ever be safely deleted. Depending on the size of the involved objects I don't think you'd have a net gain in memory footprint reduction, especially on server applications (unless you restart the server instance for "extensive garbage collection" every 24 hours or so ;)). Besides, you'd need extra state variables to mark the smart pointer as "leaking" (or you'd say that MAX_COUNT of the counter implies "leaking").


So I don't think by "stealing bits" they want to save on memory usage, do they?

Hence the big question: how then? Are there arithmetic operations such as "Increment/Decrement" which are faster on "a coupble of bits" than, say, an Integer (32 or 64 bit)? Other "bit fiddling" than one can exploit on such small values that I cannot think of right now?

("Parallel incrementing" two values packed into a single value comes to my mind - but such SIMD instructions exist for Integer (Float? Double?), and not for char values, right? And even so: how would that help if you wanted to increment ONE counter in a given smart pointer instance?)


Cheers,
  Oliver

(*) No, I am not a "hardware guy" ;) I know about Endianness. I had to read (parts of) "RISC - A Quantitative Approach" during my studies (and "quantitative" is to be taken litterally! They certainly did not think about reducing the /weight/ of that 5 kg book! ;)). I remember faintly that there are Adders and Multipliers in the ALU. And yes, I am aware that - depending on the architecture - a "Byte" is not necessarily 8 bits (but can be any number of bits, such as 16, or why not 12, fitting the "natural size"/concept of the CPU). But let's leave those details out of the equation, unless they play a crucial part in above discussion about "how to gain performance by stealing bits from your reference counters". ;)