You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: