archspec-enabled packages

• I read the conda-forge documentation and could not find the solution for my problem there.

Comes from [1], [2], [3].

---

Building package variants for different instructions sets would be helpful for the community. For example, to support AVX for those CPUs that support it, but gracefully fall back to non-AVX variants in other CPUs (e.g. Atom). The current recommendation is to not build with AVX unless upstream handles the missing instructions at runtime.

https://github.com/conda/conda/pull/9930 exposed some parts of archspec as a virtual package __archspec, the output of which can be checked with conda info:

...
          conda version : 4.9.2
    conda-build version : 3.19.1
         python version : 3.7.6.final.0
       virtual packages : __glibc=2.27=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : /opt/miniconda  (read only)
...

However, there’s no way to leverage this information as a maintainer. What should we do?

• Add run_constrained lines the same way we deal with sysroots and glibc? I don’t think __archspec itself provides enough information now. How does the maintainer know which instructions are supported there?
• @isuruf suggested a cpu_feature metapackage that can restrict this in a better way, with as many variants as architectures I presume? This might put additional burden on the maintainer, who might need to check which architectures support which instructions.

Is there a better way?

Idea 1

A Jinja function that translates instruction sets to an __archspec selection query:

run_constrained:
  - {{ cpu_feature('avx') }}  # this could be a logical expression if needed

would be

run_constrained:
  - __archspec * *sandybridge,*ivybridge,*haswell,*broadwell,*skylake,*mic_knl,*skylake_avx512,*cannonlake,*cascadelake,*icelake,*bulldozer,*piledriver,*steamroller,*excavator,*zen,*zen2
  # or whatever the "any of this would work" query syntax is in the conda selector

If a new architecture is released and it also supports AVX would involve rebuilding packages to add the new constraints.

Idea 2

A cpu_feature metapackage with variants built for instructions: these packages would need to be updated often so their run_constrained metadata is up-to-date with compatible architectures, but wouldn’t require rebuilding downstream. How could maintainers specify multiple dependencies at the same time? Would we need to build the cartesian product of all architectures combinations?

---

I don’t think any of these ideas is good enough to be the strategy we want to pursue, but hopefully it is enough to brainstorm about it!

[wolfv]

Recently my colleagues (ping @serge-sans-paille @johanmabille) have implemented a SIMD instruction set detector in xsimd: https://github.com/xtensor-stack/xsimd/blob/master/include/xsimd/config/xsimd_arch.hpp

It also comes with some sort of ordering in the “best_version”.

It has some interesting properties:

• doesn’t rely on the CPU lists / json files to be updated
• we can easily wrap it for Python, and works natively in C++ (for mamba + conda)
• will be used in Apache Arrow, xtensor and (maybe / hopefully) NumPy

I am not sure if it’s “too late” but maybe we could use this library? Either to directly create virtual packages for the different instruction sets (avx2, sse, avx512, neon), or in a different fashion to pre-filter packages.

I am very interested to ship more optimised binaries through conda-forge … we need to save the environment 😃

[h-vetinari]

Some users will likely be setting environments (e.g. conda create -n test xyz) on a device that is not the one for deployment or production.

I think that - like for CONDA_OVERRIDE_CUDA - this is a case where it would make sense to provide a similar override for those cases that need to transpose environments between different systems. Again like for the cuda case, the vast majority of users will be able to use the archspec virtual package behind the scenes, without having to do anything explicit in order to get the most appropriate binary.