ENH, TST: Bring the NumPy C SIMD vectorization interface "NPYV" to Python

[seiko2plus]

Implement new CPython extension(_simd module)

A module to bring the NumPy C SIMD vectorization interface "NPYV"

The module is designed to be extremely flexible so that it can accommodate any kind
intrinsics, also to generate a python interface almost similar to the C interface.

The main purpose of this module is to test NPYV intrinsics in python,
but still can be used as an effective solution in designing SIMD kernels.

Also, add a new command-line argument --simd-test to control of targeted
CPU features for the _simd module.

Add testing unit that covers the current implemented intrinsics

based on _simd module.

TODO:

• rework the testing unit (drop unittest)
• add a testing unit for SIMD module itself.
• apply suggested changes
• self-review and simplify data conversions
• add test unit for fused intrinsics SIMD: add fused multiply subtract/add intrinics for all supported platforms #17258
• follow NumPy/Python coding style follow @eric-wieser suggestion for naming conventions
• add test unit for partial/non-contagious intrinsics SIMD: Add partial/non-contig load and store intrinsics for 32/64-bit #17340

Disabled the following tasks, since I'm not sure which pull-request is going to merge first
[ ] add test unit for math intrinsics(sqrt, square, abs, recip) #16247

[mattip]

@seiko2plus Can you rebase this off master now that #16397 is merged?

[seiko2plus]

@mattip, The binary size of this module depending on the default value of --simd-test is about 1400kb(after striping the debugging info).
The module is mainly used for testing the NPYV through CI, so we can disable it on the building wheel via build --simd-test="".

[mattip]

Looks good overall, thanks.

[mattip]

circleCI breakage is fixed on master, so this needs a rebase/merge to clear it.

[seiko2plus]

@mattip,

circleCI breakage is fixed on master, so this needs a rebase/merge to clear it.

done, the circleCI should pass it.

[mattip]

Can you think of a way to redo numpy/core/src/_simd/_simd_inc_easyintrin.h in C rather than as large preprocessor macros?

[seiko2plus]

@mattip, yes but I will need c++(template) or python through pyas_template.py that's how the pyas template looks loops_cmp.dispatch.pyas.c. currently working on simplifying it. I will move it later into a separate pr along with doc and testing unit.

[seiko2plus]

it seems I have to remove the draft status to make Travis and Shippable fetching it

[mattip]

I think we should merge this to unlock the other PRs. It still needs docstrings, but let's leave that for a future PR. @eric-wieser what do you think?

[mattip]

I am happy to leave the documentation for another PR, which may involve some UX changes. For instance, in order to use this I must do

from `np.core._simd import targets  # what else does _simd provide?
v1 = targets['baseline'].load_f32(range(4))  # mixing dictionary access to target and modules
v2, v3 = _simd.targets['baseline'].zip_f32(v1, v1)

The size of the module is not too bad for the boost in functionality: it allows trying out all the SIMD intrinsics via python.

[eric-wieser]

The code for the new modules looks good in this patch, as do the tests that those modules behave as expected.

I haven't reviewed the SIMD tests in this PR that use the new modules to actually do the testing in any detail, but someone else can sign off on those. Alternatively, we could split them to a new PR.

[eric-wieser]

The TestUtility class seems a bit odd to me. It might make more sense as a standalone class that uses instance state - the suggestions below are incomplete but should give an overall view of what I'm suggesting.

Its tempting to make SuffixInfo class I suggest be part of the _simd module, rather than just in this one test.

[mattip]

@seiko2plus there are a couple of suggestion still open. Could you either accept them or comment? This is really close now, lets finish it up.

[seiko2plus]

@mattip, both comments were part of parameterize() suggestion, I left comments for them.

[mattip]

Thanks @seiko2plus and @eric-wieser. Please open new issues/PR for parts of this that still need iterating on, it is a large addition so there is bound to be more to finish.