s_kanev
Joined 14 years ago
Karma
125
Submissions
25
Member since
Jan 11
Recent submissions
Comment · 6 years ago
This was the case a few years back when the fastest pools were implemented with recursive data structures (e.g. linked lists for the freelists in gperftools).
In the new tcmalloc (and, I think, hoard?) the fastest pools are essentially slabs with bump allocation, so the fastest (and by far, the most common) calls are a grand total of 15 or so instructions, without many cache misses (size class lookups tend to stay in the cache). Call overhead can be a substantial chunk of that.
Comment · 6 years ago
Not OP, but I do (a fair amount of) HPDE/TT with an m240i, converted to the cup car spec.
Running costs for me are ~$500 / 2-hour day on 100-TW tires. These cars aren't exactly light, so they eat through consumables. Tires are the largest part, then repairs, then brakes. This doesn't count fuel.
If I had to guess for OP in PWC, 50-100% more, mostly driven by slick costs.
EDIT: added fuel note
Comment · 10 years ago
Both static and dynamic histograms can be pretty important, actually. Dynamic ones for performance, static ones -- usually for correctness (imagine developing a tool just like QEMU, which needs to emulate each instruction type).
Performance counters by themselves aren't granular enough for an exact histogram. But you can use them (especially the LBR[1] and the fancy new PT[2]) to reconstruct an approximate control-flow graph, and with a bit of post-processing it's easy to get per-instruction call frequencies.
A long time ago, I wrote a paper on x86 trace compression that needed a dynamic histogram like the one you mentioned. As expected, the CDF rises very very fast [3, Fig. 5] -- you can cover a very large fraction of execution with a very small number of instructions.
[1] http://lwn.net/Articles/680996/ [2] http://www.halobates.de/pt-tracing-summit15.pdf [3] http://skanev.org/papers/ispass11zcompr.pdf
Comment · 11 years ago
I beg to disagree. For instance, it's been running for years sampling Google's fleet [1] (the paper mentions oprofile, but that has been replaced quite a while ago).
[1] http://courses.cs.washington.edu/courses/cse590g/11sp/36575....
Comment · 12 years ago
Have you seen xed [1]? It seems to fit the bill nicely from what I understand about your requirements.
[1] https://software.intel.com/sites/landingpage/pintool/docs/67...
Comment · 12 years ago
My go-to practitioner:
Jean-luc Doumont: http://www.principiae.be/X0302.php
I highly recommend his talks (he tours universities in the US quite often) -- they are full of small practical nuggets on data presentation.
Comment · 12 years ago
Yeah, cpu idleness is pretty fascinating and, as it turns out, quite important. Shameless plug, I just published a paper [1], showing that if you mess up how deeply you go to sleep in cpuidle, you can loose up to ~15% latency in datacenter services like websearch.
Comment · 12 years ago
Ok, should've been more specific -- it doesn't catch any exceptions and lets them bring down the program and have the project maintainer check what they did wrong.
Comment · 12 years ago
OP here. Totally agree. TIL about RAII.
That particular codebase doesn't use c++ exceptions, but still not a reason for a roll-your-own solution if something as efficient is in the standard library.
http://blog.skanev.org/