Am 14.09.2014 um 18:43 schrieb "charleyb123 ." <charleyb...@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". ;)
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
