Gematria models show an improvement in performance on tricky code snippets when runtime annotations are enabled, but not to the degree we would have liked to see.
This is suspected to be a result of poor density of runtime annotations - i.e. very many (pseudo-)basic blocks with instructions that evidently cache miss don't have the corresponding cache miss annotation, because cache misses caused by those instruction are "missed" while sampling.
In attempt to get more samples, so far we've tried to:
- change the sampling frequency (
perf record -F),
- change the number of events counted before a sample is recorded (
perf record -c).
But it might take some more investigating/experimenting with perf to try to record a satisfactory amount of samples. To illustrate, perf record -c 1 ... should record as many samples every single sample, but might not be doing so because we were also counting CYCLES events, and doing so at that frequency might have adverse effects on how many samples we end up collecting.
Gematria models show an improvement in performance on tricky code snippets when runtime annotations are enabled, but not to the degree we would have liked to see.
This is suspected to be a result of poor density of runtime annotations - i.e. very many (pseudo-)basic blocks with instructions that evidently cache miss don't have the corresponding cache miss annotation, because cache misses caused by those instruction are "missed" while sampling.
In attempt to get more samples, so far we've tried to:
perf record -F),perf record -c).But it might take some more investigating/experimenting with
perfto try to record a satisfactory amount of samples. To illustrate,perf record -c 1 ...should record as many samples every single sample, but might not be doing so because we were also countingCYCLESevents, and doing so at that frequency might have adverse effects on how many samples we end up collecting.