4 ms·
The real thing we care about is "wasted processor cycles", as well as their source. We measure some sources (branch mispredictions, instruction cache thrashing
by halomru 10y ago
The real thing we care about is "wasted processor cycles", as well as their source. We measure some sources (branch mispredictions, instruction cache thrashing etc.) and some potential sources (e.g. cache misses). What we lack is a metric how bad each instance is. Not every branch misprediction has the same cost. With cache misses the cost can be nearly zero or very high. It would be nice to be able to measure (or simulate or estimate) the real magnitude of each problem.
As long as we don't have that, cache misses are a useful metric on their own, as long as one is aware of its caveats. As most things, cache misses come in various shades of grey.
- onetimePete 10y agoSo you suggest cache misses corrected by a instruction-workload bias (which should be again biased by how "hot" the instructions remain)? EvilOfCacheMiss = TimeOfMemoryFetchCycles - CyclesSpendDoingInstructions /TimeOfMemoryFetchCycles
- azernik 10y agoMore like TimeOfMemoryFetchInCycle - CyclesSpentDoingInstructions But yeah, sounds like a useful metric to me.
- matt_d 10y agoThis discussion reminded me of a formula for calculating the average cost of a cache miss in this pretty cool paper ("An Analysis of the Effects of Miss Clustering on the Cost of a Cache Miss"). In particular, see Equation 4: http://researcher.ibm.com/files/us-viji/miss-cluster.pdf http://researcher.ibm.com/files/us-viji/miss-cluster.pdf