s_kanev

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.

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

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

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....

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...

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.

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.

[1] http://www.skanev.org/papers/iiswc14ep.pdf

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.

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.

Spent a few hours trying to look into this. The results so far suggest it has to do with the register renaming mechanism, but not completely conclusive. You can check out my notes here: http://blog.skanev.org/2013/12/call-performance-weirdness.ht...

For an intro read, Hennessy and Patterson's "Computer Organization and Design" is good. Their other book, "Computer Architecture: A Quantitative Approach" is the de facto bible, but it's slightly more advanced, and not a good first read. Another good intro book is "Computer Systems: A Programmer's Perspective" - especially for software people.

Disclaimer: I was a '12 grad, and currently doing a PhD in CS there.

> because some of the faculty just weren't that great

I think this is anecdotal evidence against anecdotal evidence. In my case, a lot of the faculty were that great. A few concrete names that immediately pop to mind would be: Margo Seltzer, Mike Smith, Greg Morrisett, Matt Welsch (now at google), David Malan, Howard Georgi, ...

> admissions office [..] selects [..] "excellent sheep"--kids who do (or appear to do) what they're told extremely well

Au contraire, my anecdotal evidence is that the admissions office tends to lean a lot on the "liberal arts" side. I come from a background with a strong respect of science and academics, and would often get very surprised to see some people not focus on those areas as much. But then I'd see them play their instrument, direct a play, qualify for the Olympics, etc. Most of those people ended up in consulting or teaching (TFA and the like) actually.

But no, I am not going to argue that a lot of people don't end up on Wall Street. And quite frankly, I don't see anything wrong with that. In the tech sector, we are quite fortunate that a large fraction of funding is provided through VCs. But a lot of other sectors don't have that luxury and need to resort to other sources of liquidity, private equity firms and i-banks. In those areas, it is much harder to define an actual measure of product goodness (in CS, we can always say that app X runs Y% faster or that Z% of the large number of users prefer it), and individual performance is evaluated much more based on _soft skills_. This is the exact skill set that is developed by the non-acacdemic parts of college. As tech people, we might feel cheated in some sense by that (the same way we feel cheated by a good salesman who "doesn't contribute anything"), but as long as there are requirements for capital, I don't see any alternative.

edit: grammar

For such purposes, binary instrumentation is probably a more proper tool. Various options out there, I personally prefer Pin [1] because it's extremely robust and gives you good control of the overheads from instrumenting.

edit: grammar

[1] http://software.intel.com/en-us/articles/pin-a-dynamic-binar...

http://blog.skanev.org/ -- a weird mix about academia (PhD student in computer architecture), photography (still advanced amateur) and long-distance running (marathoner).

These are all valid points for high-level languages in general. One can add easier parametrization to the list (high-performing HDL code can be terrible to reparametrize).

I was mostly surprised by the choice of a Haskell-based DSL. I think such languages miss their target audience. Most people writing in an HDL are hardware designers without significant software training (I am fortunate to be a software-turned-hardware person). For them making the jump to, f.e. a functional paradigm (as in Bluespec), is much harder compared to a lesser, more popular evil (C/C++ based DSLs like SystemC or AutoESL).

I'm a bit surprised by the workflow. While I agree that hardware description languages are terrible from a software developer point of view, to me Verilog is typically much more tolerable than VHDL. Also, in the last few years, SystemC has been getting much more popular as the high-level step before Verilog/VHDL.

This is not completely true. "Authors and/or their employers shall have the right to post the accepted version of IEEE-copyrighted articles on their own personal servers or the servers of their institutions or employers without permission from IEEE..." [1]. They also allow preprints on personal sites. The other major publishing organization in CS, ACM, has a similar policy.

[1] https://www.ieee.org/documents/ieeecopyrightform.pdf