Dynamically detect PMU capabilities through libpfm

[damageboy]

Dynamically detect PMU capabilities through libpfm

• Instead of allowing for up to 3 counters, libpfm's internal capabilities of reporting PMU info are used to manage a per-PMU "registry" and dynamically allocate "slots" according to the specific counters requested.
• per-PMU information is obtained, where each PMU reports its own capabilities in the form of fixed/non-fixed counter limits.
• In this PR/commit, it is still impossible to get more detailed (x86-only) counter information in terms of fixed/non-fixed counter association, due to what seems to be a lack of API surface on libpfm itself: https://sourceforge.net/p/perfmon2/mailman/message/37631173/
• The maximal number of counters is bumped from 3 to 63, which together with the current padding "scheme" means we pre-allocate/inlline up-to 64 counter slots (64-bits each) per measurement instance
• Closes #1377

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

For more information, open the CLA check for this pull request.

[damageboy]

also check the format issues please. use clang-format, ideally.

Yeah, sorry about that, I was editing the file through a different project with its own .clang-format and it got mixed up.

[dmah42]

can you check those bot failures please?

[damageboy]

can you check those bot failures please?

Sure on it!

[damageboy]

can you check those bot failures please?

Well, apart from the formatting error, the build errors are from that (apparently) not so innocent that was part of the pre-existing code that you requested: https://github.com/google/benchmark/pull/1380#discussion_r841551848

Reverting that unrelated change seems to have solved the issue locally for me when building with:

cmake ../ -G Ninja -DCMAKE_BUILD_TYPE=Release -DBENCHMARK_ENABLE_WERROR=ON -DBENCHMARK_ENABLE_TESTING=OFF

The formatting issues have been fixed too.

[dmah42]

can you check those bot failures please?

Well, apart from the formatting error, the build errors are from that (apparently) not so innocent that was part of the pre-existing code that you requested: #1380 (comment)

Reverting that unrelated change seems to have solved the issue locally for me when building with:

cmake ../ -G Ninja -DCMAKE_BUILD_TYPE=Release -DBENCHMARK_ENABLE_WERROR=ON -DBENCHMARK_ENABLE_TESTING=OFF

The formatting issues have been fixed too.

ah crap, sorry for the extra churn then.

[damageboy]

@dominichamon I'm having a hard time reproing the build issues on a pristine ubuntu 16.04 with gcc-5 using a local docker image. Do you have any ideas on how I can repro the build breakage? Referring to this:

https://github.com/google/benchmark/runs/5850874474?check_suite_focus=true:

/__w/benchmark/benchmark/src/perf_counters.cc:145:52:   required from here
/usr/include/c++/5/bits/hashtable_policy.h:85:34: error: no match for call to '(const std::hash<pfm_pmu_t>) (const pfm_pmu_t&)'
  noexcept(declval<const _Hash&>()(declval<const _Key&>()))>

[dmah42]

@dominichamon I'm having a hard time reproing the build issues on a pristine ubuntu 16.04 with gcc-5 using a local docker image. Do you have any ideas on how I can repro the build breakage? Referring to this:

https://github.com/google/benchmark/runs/5850874474?check_suite_focus=true:

/__w/benchmark/benchmark/src/perf_counters.cc:145:52:   required from here
/usr/include/c++/5/bits/hashtable_policy.h:85:34: error: no match for call to '(const std::hash<pfm_pmu_t>) (const pfm_pmu_t&)'
  noexcept(declval<const _Hash&>()(declval<const _Key&>()))>

i haven't seen this error before. it smells a bit like an ABI mismatch, which suggests the bots are misconfigured, but i don't think this has been true until now.

it suggests we don't have a std::hash for pfm_pmu_t...

[damageboy]

en this error before. it smells a bit like an ABI mismatch, which suggests the bots are misconfigured, but i don't think this has been true until now.

Yes, I realize this, to make things worse, this doesn't happen on a brand new printine ubuntu 16.04 docker image I ran locally. It just compiles cleanly... :(

[dmah42]

ping .. are you planning on coming back to finish this off? it would be really good to be able to merge it.

[dmah42]

one more check to see if there's any plans to come back to this...