Should we use hardware/family IDs for identifying required/optimized_for targets or a bag of hardware characteristics?

[masonremy]

A bag of characteristics, such as cache sizes, cache line sizes, different GPU memory segment sizes, clock speed, etc. makes it easier to find a .hat file containing functions that give the "closest match" to the hardware you're targeting if there isn't an exact matching .hat file for your hardware. Including relevant characteristics in the .hat file means that any user of the .hat file can do a simple nearest-neighbor or some other thresholding approach to find the right function to use.
However, many types of hardware continue to add more differentiating components, which will each need their own category (e.g. tensor cores on a GPU) and as more tailored hardware arises over time this problem will continue and we'll either need to rev the schema repeatedly to account for each category or encapsulate it all in an "auxiliary" section, in which case arguably none of it should be in the schema and it should all be auxiliary. This then favors using only hardware IDs and potentially hardware family IDs (e.g. "Haswell", "Ampere", etc), and placing the work of finding a "closest match" on the consumer of the HAT package. The consumer would then need to encode and pivot on hardware spec information that is relevant to their use.

Both scenarios require the consumer of a HAT package to do no work if there is an exact match or some work if there isn't an exact match. The tradeoff is whether there is more work determining a closest match placed on the consumer of HAT packages or more work placed on the maintainers of the HAT schema and HAT package producers.