cpu_features icon indicating copy to clipboard operation
cpu_features copied to clipboard

Support disabling of extensions

Open c0d1f1ed opened this issue 5 years ago • 3 comments

To test all code paths of apps that use cpu_features to select between different implementations of an algorithm, it would be useful to be able to mock having a CPU with fewer features than actually supported.

While this can be done in wrapper layer which uses cpu_features to query the real feature set, little prevents direct use of cpu_features functions that would break the purpose of the wrapper. Hence I think it would be useful if this was a core feature of cpu_features itself.

One complication is that for tests to be able to run concurrently this would have to be thread-local (assuming the tests are single-threaded). For multi-threaded tests a global mutex could be used to prevent concurrent execution from the point where cpu_features is provided with override options, to the point where they're removed.

Multiple users of cpu_features have to deal with this themselves currently, so having it as a core feature instead avoids duplicate effort and incompatible solutions which might have subtle bugs that are best fixed centrally.

c0d1f1ed avatar Jan 15 '20 18:01 c0d1f1ed

Thx for the suggestion @c0d1f1ed. I think it's a great idea. Let me think about how to implement it.

gchatelet avatar Jan 16 '20 09:01 gchatelet

@c0d1f1ed would something along the lines of eb59787849400f93167ee7a1945591232e487e78 work for you? Do you see any shortcomings?

gchatelet avatar Jan 17 '20 15:01 gchatelet

One minor concern (or rather a follow-up feature request) is that it's non-trivial to know which set of extensions is supported by each CPU micro-architecture. Even just the mix of SSE4.1, SSE4.2, SSE4a, POPCNT, and LZCNT one can end up with in practice gets confusing quite quickly (https://en.wikipedia.org/wiki/SSE4#Supporting_CPUs). It's common for software to check for one of these features and end up using instructions from the other sets. Sometimes that's valid, sometimes it's not.

Likewise even when we disable all features not supported by a certain micro-architecture, when new extensions come along those would remain enabled unless we (and all other cpu_features users that use mocking) update our code.

So it would be super helpful if cpu_features can mock specific micro-architectures (or an intersection of the features of the CPU we're running on and the one we're trying to not exceed its feature set), and keep that up to date.

c0d1f1ed avatar Jan 17 '20 18:01 c0d1f1ed