| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We would like to extend CPU feature detection infrastructure
for IBM Z CPU features. Eventually It will help to add and
enable Z specific SIMD builtins and instructions.
As part of the PR, we have extended ccompiler_opt.py,
npy_cpu_features.c.src, npy_cpu_features.h, other files for
Z CPU feature detection and added test files for VX/VXE/VXE2
in distutils/checks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- use plain variables
- clean up aligned allocate
- use `PyArg_ParseTuple` for empty args
- use `Py_ssize_t` instead of `unsigned` and `size_t`
- improve coding style
- no need for a custom raises assertions
- use parametrize instead of inner loops
- leave a comment about nature of mode testing unit
- shift to get max/min of int72
- add more info to repr of vector object
- get ride of exec() and use type() instead
- use `.inc` as extension for sub-headers instead of `.h`
- add `FMA4` and drop `SSE41` from _SIMD targets
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'_simd' is a new 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.
Co-authored-by: Matti Picus <matti.picus@gmail.com>
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Put `CCompilerOpt` in action through add two command line
arguments that passed directly to `CCompilerOpt`'s
parameters which explained as follows:
* `--cpu-baseline` minimal set of required optimizations,
default 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 is 'max-xop-fma4' which enables all CPU features,
except for AMD legacy features.
the new arguments can be reached from `build`, `build_clib`,
`build_ext`, if `build_clib` or `build_ext` are not specified
by the user the arguments of `build` will be used, which also
hold the default values.
- Activate the new compiler dispatcher that comes with `CCompilerOpt`,
through adding a hock inside `build_clib` and `build_ext`
that works as a filter taking any C source files ends with
`.dispatch.c` and pass it directly to `CCompilerOpt` and
then take returned objects and linked to the final C lib.
- Add a third command-line argument `--disable-optimization` which
explicitly disable the whole new infrastructure, also
It adds a new compiler definition called `NPY_DISABLE_OPTIMIZATION`.
when `--disable-optimization` is enabled the dispatch-able sources
that end with `.dispatch.c` will be treated as a normal
C sources, also due to this disabling any C headers that
generated by `CCompilerOpt` must guard it with `NPY_DISABLE_OPTIMIZATION`,
otherwise, it will definitely break the build.
- New auto-generated C header located at `core/include/numpy/_cpu_dispatch.h`,
the new header contains all definitions and headers of CPU features that
enabled according to specified configuration in `--cpu-baseline`
and `--cpu-dispatch`.
|
| |
|
|
|
| |
As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
python3.5 uses --parallel instead of --jobs
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow extensions using numpy.distutils to compile in parallel.
By passing `--jobs=n` or `-j n` to `setup.py build` the compilation of
extensions is now performed in `n` parallel processes.
Additionally the environment variable NPY_NUM_BUILD_JOBS is used as
the default value, if its unset the default is serial compilation.
The parallelization is limited to within the files of an extension, so
only numpy multiarraymodule really profits but its still a nice
improvement when you have 2-4 cores.
Unfortunately Cython will not profit at all as it tends to build one
module per file.
|
| |
|
|
|
|
|
| |
Run the 2to3 ws_comma fixer on *.py files. Some lines are now too long
and will need to be broken at some point. OTOH, some lines were already
too long and need to be broken at some point. Now seems as good a time
as any to do this with open PRs at a minimum.
|
| |
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new import `absolute_import` is added the `from __future__ import`
statement and The 2to3 `import` fixer is run to make the imports
compatible. There are several things that need to be dealt with to make
this work.
1) Files meant to be run as scripts run in a different environment than
files imported as part of a package, and so changes to those files need
to be skipped. The affected script files are:
* all setup.py files
* numpy/core/code_generators/generate_umath.py
* numpy/core/code_generators/generate_numpy_api.py
* numpy/core/code_generators/generate_ufunc_api.py
2) Some imported modules are not available as they are created during
the build process and consequently 2to3 is unable to handle them
correctly. Files that import those modules need a bit of extra work.
The affected files are:
* core/__init__.py,
* core/numeric.py,
* core/_internal.py,
* core/arrayprint.py,
* core/fromnumeric.py,
* numpy/__init__.py,
* lib/npyio.py,
* lib/function_base.py,
* fft/fftpack.py,
* random/__init__.py
Closes #3172
|
| |
|
|
|
|
|
|
| |
This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.
|
| |
|
|
|
|
|
| |
setuptools develop run build_ext inplace, not build, so develop command in
setuptools would not call the scons command. Now, the develop mode should work
with numscons.
|
| | |
|
| | |
|
| |
|
|
| |
--compiler,--help-compiler options.
|
| |
|
|
| |
for unifying --compiler options.
|
| |
|
|
| |
--fcompiler can be specified only once in a command line
|
| | |
|
| |
|
