Awesome! Will be useful for enabling things like numpy/numpy#13516, I'm guessing. Even though it'd be another dimension on the build-matrix, there's probably 2-3 variants that'd be worth building for...?

numpy/numpy#13516 is a different thing which has runtime cpu detection within numpy itself.

Are you 100% sure? It seems heavily dependent on many things at build time:

New Build Arguments

• --cpu-baseline minimal set of required optimizations, default value is min which provides the minimum CPU features that can safely run on a wide range of users platforms.
• --cpu-dispatch dispatched set of additional optimizations, default value is max -xop -fma4 which enables all CPU features, except for AMD legacy features.

The new arguments can be reached through build, build_clib, build_ext. [...]

New auto-generated C header (core/src/common/_cpu_dispatch.h)

The new header contains all the definitions and headers of instruction-sets for the CPU baseline and dispatch-able features that have enabled through command arguments --cpu-baseline and --cpu-dispatch.

NPY_HAVE_ is the suffix of CPU features definitions, e.g. NPY_HAVE_SSE2, NPY_HAVE_VSX, NPY_HAVE_NEON.

The default minimum does not include AVX on x86, for example.

But numpy PR aside, IIUC, this should enable to have different compiler builds per (group of) cpu features, right?

But numpy PR aside, IIUC, this should enable to have different compiler builds per (group of) cpu features, right?

Yes

@jjhelmus, @mingwandroid, @katietz, any thoughts on this?

ping on this

ping on this again

xref #10057 regarding fixing virtual packages just in case this is relevant.

@isuruf: can you please provide some context for this and (possibly) PR#9461? Having conda provide information about the CPU it's running on seems handy, but I'm curious if you had specific use cases in mind.

Also, with this PR, would you want to make conda explicitly dependent on the archspec package? It seems a little odd to me to have the virtual package build string, and thus what conda info reports, dependent on an optional package.

@isuruf: can you please provide some context for this and (possibly) PR#9461? Having conda provide information about the CPU it's running on seems handy, but I'm curious if you had specific use cases in mind.

Sure. There are some packages that don't support runtime detection of CPUs and they need to be built for different architectures. With the CPU type available in the solver, we can build different variants of the same package and make sure the correct package is installed.

Also, with this PR, would you want to make conda explicitly dependent on the archspec package? It seems a little odd to me to have the virtual package build string, and thus what conda info reports, dependent on an optional package.

I'm fine with any option.

@isuruf Could you provide an example here as for how to use this feature, perhaps from recipe maintainers' perspective? I am lost by looking at the changes...

cc: @beckermr (Maybe you knew this already, @isuruf pointed out to me that this PR could help build packages for avoiding avx512.)

@leofang, it's up to the downstream packages on how to use this. I was thinking of adding a cpu_feature meta package to conda-forge so that people can say - cpu_feature * *_haswell in host in conda-build.

cc @manodeep on using this in the corrfunc feedstock

Hi there, thank you for your contribution to Conda!

This pull request has been automatically locked since it has not had recent activity after it was closed.

Please open a new issue or pull request if needed.