Open migueldiascosta opened 3 years ago
further discussion: I would suggest than when a generic architecture is detected by archspec, eessi_software_subdir_for_host.py
would ouput a message with the closest but not strictly compatible match (e.g., in the case of x86_64_v3
it would be haswell
) and noting that users can set EESSI_SOFTWARE_SUBDIR_OVERRIDE
, at their own risk
In this situation at least one feature (e.g. aes
) of the not strictly compatible closest match will not be present/enabled in the host cpu, but if that feature isn't actually used, overriding allows making good use of everything else (in particular, the correct avx
level)
Of course, if EESSI moves to using the generic levels as targets instead of the vendor specific ones (which would require not building with native
but with the host's highest generic level instead), then this would be no longer an issue and each EESSI target would be compatible with more host cpus, while still making use of the most important features, performance wise, in each level, at the cost of not making use of (less important, performance wise, imh(and speculative)o) vendor specific features...
once https://github.com/archspec/archspec/pull/53 is merged,
eessi_software_subdir_for_host.py
will need to be slightly modified because archspec in some circunstances will detect ageneric
architecture (e.g.x86_64_v3
) with ageneric
vendor string, which will need to be added toVENDOR_MAP
(otherwisehost_vendor
will beNone
, tripping theos.path.join
infind_best_target
)EDIT: Once that is done,
eessi_software_subdir_for_host.py
will continue to fallback tox86_64/generic
if it can't find a compatible target.