[PATCH] D20914: [esan|cfrag] Compute the struct field access variance

[Mike Aizatsky via llvm-commits]

aizatsky requested changes to this revision.
This revision now requires changes to proceed.

================
Comment at: lib/esan/cache_frag.cpp:45
@@ -43,1 +44,3 @@
+  u64 Count;      // The total access count of the struct.
+  u64 Difference; // Difference score for the struct layout access.
 };
----------------
Let's call it ratio then.

================
Comment at: lib/esan/cache_frag.cpp:54
@@ -50,2 +53,3 @@
   u64 TotalCount; // The total access count of all structs.
+  u64 TotalDifference;
 };
----------------
If we are sticking to a ratio, then Sum(ratios) doesn't make lots of sense.

This is the whole-program metric, right?

How about considering (one of) the following metrics (Ci - counts, Ri - ratio):

1) Sum(Abs(Ci - C{i+1}))?  - Total "Assymetry". You can divide it by TotalCount to get a relative metric.

2) Max(Ri) (Mean, Median, StdDev, GeomMean)

BTW if you want this in sooner, I suggest you remove TotalDifference from this CL altogether, and let's figure it out in a separate one?


================
Comment at: lib/esan/cache_frag.cpp:63
@@ +62,3 @@
+
+// FIXME: we are still exploring proper ways to evaluate the difference between
+// struct field counts.  Currently, we use a simple formula to calculate the
----------------
The only reason to use log is to make huge differences look smaller. I suspect that this is not your case - you want huge differences look huge, because CPUs are linear. I approve the use of the linear scale.

================
Comment at: lib/esan/cache_frag.cpp:70
@@ +69,3 @@
+  if (Base == 0) Base = 1;
+  return (Val1 / Val2 / Base);
+}
----------------
Unless there is an overflow concern (which there shouldn't be, right?), I suggest storing the unscaled ratio. You can always introduce scaling when you print.


http://reviews.llvm.org/D20914