Sometimes Hardware Counters per Op are reported as NaNs

[adamsitnik]

dotnet run -c Release -f netcoreapp5.0 --filter Burgers.Test0 --profiler ETW --counters InstructionRetired

Method	Mean	Error	StdDev	Median	Min	Max	Gen 0	Gen 1	Gen 2	Allocated	InstructionRetired/Op
Burgers_0	268.2 ms	8.24 ms	9.49 ms	264.7 ms	258.6 ms	288.5 ms	101000.0000	-	-	763.32 MB	NaN

Source code

[adamsitnik]

Update: it's true only for long-running benchmarks where we skip the overhead phase

[abelbraaksma]

I've reported a while ago #1337 and #1338 related to wrongly calculating by a factor of 1000 or so the "skip overhead" or "run only once per iteration" for long-running benchmarks, leading to very wrong results because benchmarks are wrongly considered "long".

Not sure it's the same cause/result, but I've been trying to understand what was going on there for a while now and I assumed it had to do with JIT-time being accidentally taken into account for testing whether an op is "long-running".

I reported there that PR #760 included code that skips the pilot phase, but that code uses wrong assumptions (or it's caused by the bug you reported here. Which would be wonderful, as since #760 it's been virtually impossible to run BDN reliably on fast code that involves a lot of indirect JIT).