Add hardware counter profile

[bugRanger]

SUMMARY

It's great that version 1 added counter support, but the expected counter names don't always match what the system provides.

Based on previous attempts (1, 2), providing free input strings provides versatility, but there are also drawbacks:

• Inconvenient for teams working in different configurations;
• Strings in attributes lead to a lot of duplicate code;

Therefore, an option with a profile description for extracting the required value sets could solve these problems.

UPD: Added simple test for ETW with custom profile, output result:

BenchmarkDotNet v0.16.0-develop (2026-06-25), Windows 10 (10.0.19045.6456/22H2/2022Update)
AMD Ryzen 7 5700G with Radeon Graphics 3.80GHz, 1 CPU, 16 logical and 8 physical cores
Memory: 27,9 GB Total, 13,77 GB Available
.NET SDK 10.0.103
  [Host] : .NET 8.0.24 (8.0.24, 8.0.2426.7010), X64 RyuJIT x86-64-v3
  Dry    : .NET 8.0.24 (8.0.24, 8.0.2426.7010), X64 RyuJIT x86-64-v3

Job=Dry  IterationCount=1  LaunchCount=1  
RunStrategy=ColdStart  UnrollFactor=1  

| Method         | Mean     | Error | FakeCacheMisses1/Op | FakeCacheMisses3/Op | FakeCacheMisses2/Op |
|--------------- |---------:|------:|--------------------:|--------------------:|--------------------:|
| SortedBranch   | 143.1 μs |    NA |             581,632 |             581,632 |              45,056 |
| UnsortedBranch | 180.3 μs |    NA |             577,536 |             577,536 |              45,056 |

[bugRanger]

@dotnet-policy-service agree

[timcassell]

It's an interesting approach. But it looks like you can only remap existing HardwareCounter enum members to machine-specific hardware counter names. I'm by no means an expert when it comes to hardware counters, but do we need to handle the case of a hardware counter that is not mapped to an existing enum member? Or in those cases we will just need to expand the enum to cover new cases?

[filzrev]

If this project is not expected to be executed on CI.

Is it able to define these tests on BenchmarkDotNet.IntegrationTests.ManualRunning project side?

[filzrev]

This test has ETW namespace.
Is this test works on non-Windows environment?

[timcassell]

I would not expect it to. #388 (comment)

[filzrev]

I would not expect it to.

In that case, I think it need to replace [Fact] to use [EnvSpecificFact(EnvRequirement.WindowsOnly)].

[bugRanger]

It's an interesting approach. But it looks like you can only remap existing HardwareCounter enum members to machine-specific hardware counter names. I'm by no means an expert when it comes to hardware counters, but do we need to handle the case of a hardware counter that is not mapped to an existing enum member? Or in those cases we will just need to expand the enum to cover new cases?

This is a good question! 👍

I welcome any criticism, as even now I feel like my solution doesn't fully address or reflect the problem.

A little context
Apparently, performance counters across different manufacturers aren't coordinated in any way and don't adhere to any clear standard. This is evident in how the Windows operating system HAL itself attempts to solve the same problem using ProfileSources (I don't claim this information is up-to-date; perhaps someone has more recent data than I do).

As far as I understand, ProfileSources includes a set of counters familiar to Windows and excludes many vendor-specific counters. But, apparently, these counters aren't ignored, but rather somehow registered by the system and made available in ETW.

However, it is worth noting that all the approaches described above understand the configuration on which they are running, while our performance testing script is described by a set of attributes or a launch configuration and does not know what system it will run on.

Results
I don't think we can't fully cover the entire set of counters from different manufacturers or attempt to fully map them as is done in HAL.

In my solution, the old version of HardwareCounter (which mapped directly to the counter name) is used as an abstraction when connecting the counter. This provides an advantage when setting up a benchmark scenario, as you don't need to specify which processor models the code should run on, but it does require the executor to load a profile that will implement the necessary performance counter mapping.

However, I wouldn't remove the old version, which attempts to directly map HardwareCounter to the required counters. I think it could be improved by allowing it to determine which counters it can use from the available enumeration for a given machine at the time the benchmark is launched (use table ProfileSources).

P.S.
After all that, I took another look at my proposed solution and it seems the API may be unintuitive and confusing for developers.

[bugRanger]

#1520

[bugRanger]

Planned list of changes:

• Add predefined counter sets (see Hardware Performance Counters - Emon/AMD/Default).
  • Selection criteria: only counters that are present in the majority and are frequently used.
• Add a log of available counters when running a benchmark (if there is at least one unknown counter).
• Allow the ability to create a custom counter set (named on the machine, named in the report).