pystencils issueshttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues2024-03-27T17:25:53+01:00https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/88Clarify semantics of fancy integer division functions2024-03-27T17:25:53+01:00Frederik HennigClarify semantics of fancy integer division functionsThe functions `modulo_floor`, `modulo_ceil`, `div_floor` and `div_ceil` of the `integer_functions` exhibit unclear rounding behaviour. Their names and docstrings indicate mathematical rounding behaviour ("down" is negative infinity), whi...The functions `modulo_floor`, `modulo_ceil`, `div_floor` and `div_ceil` of the `integer_functions` exhibit unclear rounding behaviour. Their names and docstrings indicate mathematical rounding behaviour ("down" is negative infinity), while their implementation performs zero-oriented rounding ("down" is toward zero), as this is the default behaviour of C `/` and `%`.
We should clarify the semantics of these functions and adapt docstring, implementation, or both.
See also the discussion here: pycodegen/pystencils!368Release 2.0Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/87Symbolic Language2024-03-27T17:25:53+01:00Frederik HennigSymbolic LanguageThe new backend must support the full symbolic language that pystencils offered previously, plus some sensible additions. For now, however, the focus should be on implementing code generation support for all previously supported SymPy fe...The new backend must support the full symbolic language that pystencils offered previously, plus some sensible additions. For now, however, the focus should be on implementing code generation support for all previously supported SymPy features, as well as everything in `pystencils.sympyextensions` and a few other submodules that add features to kernels.
## Symbolic Language Consolidation
All symbolic language features should be collected into the `pystencils.sympyextensions` module (as also discussed in pycodegen/pystencils#47).
Furthermore, the documentation should include a section that fully documents all SymPy features and our extensions which the code generator supports. This section should also point out any restrictions and caveats.
- [ ] Set up symbolic language documentation
## FreezeExpressions
The language of pystencils will basically encompass everything that `pystencils.backend.FreezeExpressions` can translate.
Various pystencils features are still unimplemented:
- [ ] Augmented Assignments
- [ ] AddressOf
- [ ] Relations (sp.Relational)
- [ ] pystencils.sympyextensions.integer_functions
- [x] Bitwise ops
- [x] Integer Division
- [ ] Fancy division operations (see pycodegen/pystencils#88)
- [ ] pystencils.sympyextensions.bit_masks
- [ ] GPU fast approximations (pystencils.fast_approximation)
- [ ] ConditionalFieldAccess
- [ ] sp.Piecewise
- [ ] sp.floor, sp.ceiling
- [ ] sp.log, sp.atan2, sp.sinh, sp.cosh. sp.atan
- [ ] sp.Min, sp.Max: multi-argument versions
- [ ] Modulus (sp.Mod)
- [ ] Folding functions (`sp.Sum`, `sp.Product`, see pycodegen/pystencils#55)
## Random Number Generation
The random number generators currently implemented in `pystencils.rng` must be integrated with the new backend, in particular with `FreezeExpressions`.
- [ ] Integrate RNGs
## Control Flow Structures
With the removal of the old `astnodes` module, there is currently no way to express control flow in the front-end / the symbolic language.
We should discuss whether, and how, we should introduce loops and conditionals into that language again.https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/86Migrate test cases & notebooks2024-02-28T11:48:46+01:00Frederik HennigMigrate test cases & notebookshttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/85Staggered Kernels2024-03-15T09:55:35+01:00Frederik HennigStaggered KernelsThe code generator for staggered kernels must be re-implemented using the new backend.The code generator for staggered kernels must be re-implemented using the new backend.https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/84CPU Platforms and Transformations2024-03-15T10:39:04+01:00Frederik HennigCPU Platforms and Transformations# CPU Recognition and JIT
- [ ] Implement CPU auto-recognition for the `CurrentCPU` target
- [ ] Re-introduce field size equality checks to the CPU JIT compiler
- [ ] Replace the legacy CPU just-in-time compiler with an object-orient...# CPU Recognition and JIT
- [ ] Implement CPU auto-recognition for the `CurrentCPU` target
- [ ] Re-introduce field size equality checks to the CPU JIT compiler
- [ ] Replace the legacy CPU just-in-time compiler with an object-oriented, modular structure
# CPU Optimizations
The sequence of optimizations applied to a CPU code shall be controlled and carried out by the CPU optimization driver `pystencils.backend.kernelcreation.cpu_optimization.optimize_cpu`. Each individual optimization pass shall be implemented in a dedicated class within the `pystencils.backend.kernelcreation.transformations` module.
## Loop Optimizations
- [ ] OpenMP
- [ ] Loop-Invariant Code Motion: Fixpoint analysis and transformer to extract loop-invariant code
- [ ] Loop Cutting and condition elimination
- [ ] Loop tiling / blocking
## Vectorization
Vectorization shall be implemented as a two-step procedure.
### Generic Vectorization
In the first phase, the generic vectorizer shall analyze the target loop's body. If it is vectorizable, it shall be vectorized by adapting all data types to their respective vector types; adapting the loop range and, if necessary, create a remainder loop; and replace array accesses with vectorized array accesses.
- [ ] Implement vectorization legality analysis
- [ ] Implement vector transformation
### Intrinsics Selection
The second phase is intrinsics selection. The vectorizer calls upon the platform, which must be a subclass of `GenericVectorCpu`, to map all vectorized operations onto intrinsic functions. The intrinsic selection pass shall be implemented in `pystencils.backend.transformations.select_intrinsics.MaterializeVectorIntrinsics`. This class interacts with the protocols defined in `pystencils.backend.platforms.GenericVectorCpu` to retrieve the actual intrinsics depending on the vector architecture.
- [x] Implement protocols to select vector type, constant, load, store, and arithmetic intrinsics
- [ ] Implement protocols to select variable broadcast intrinsics
- [ ] Implement protocols to select mathematical function intrinsics (e.g. trigonometry, transcendentals, ...)
### X86
Intrinsic selection for X86 is implemented in `pystencils.backend.platforms.x86`:
- [x] vector types
- [x] constants
- [x] arithmetic intrinsics
- [x] aligned and unaligned load/store
- [ ] gather/scatter
- [ ] variable broadcast
### ARM
Intrinsic selection for ARM shall be implemented in `pystencils.backend.platforms.arm`:
- [ ] vector types
- [ ] constants
- [ ] arithmetic intrinsics
- [ ] aligned and unaligned load/store
- [ ] gather/scatter
- [ ] variable broadcasthttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/83GPU Platform2024-03-15T09:54:26+01:00Frederik HennigGPU Platform## Kernel creation for GPUs
- [ ] Implement CUDA GPU platform into `pystencils.backend.platforms`
- [ ] Implement GPU indexing and iteration space materialization (might want to re-use the existing `GpuIndexing` classes)
## Parameter...## Kernel creation for GPUs
- [ ] Implement CUDA GPU platform into `pystencils.backend.platforms`
- [ ] Implement GPU indexing and iteration space materialization (might want to re-use the existing `GpuIndexing` classes)
## Parameterization
- [ ] Implement automatic GPU detection for the `CurrentGPU` target
- [ ] Add GPU options to `CreateKernelOptions`
## JIT
- [ ] Implement CUDA just-in-time compilation into `pystencils.backend.jit`https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/82C++ Code Printer2024-03-12T11:14:20+01:00Frederik HennigC++ Code Printerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/81Improved Expression Manipulation
2024-03-10T17:59:43+01:00Frederik HennigImproved Expression Manipulation
## Freeze
`FreezeExpressions` is currently still quite naive; it should be more intelligent and take SymPy's peculiarities into account:
- Expand `Pow` to multiplications where sensible
- Detect subtractions (e.g. a + (-1 * b)) and m...## Freeze
`FreezeExpressions` is currently still quite naive; it should be more intelligent and take SymPy's peculiarities into account:
- Expand `Pow` to multiplications where sensible
- Detect subtractions (e.g. a + (-1 * b)) and map them to `PsSub`
- [x] Extend `FreezeExpressions`
## Constant Folding
The new AST is completely static, but constant folding will be necessary as a general optimization and during many transformations. Integers can always be folded; we should be more conservative about floating-point constants.
- [x] Implement a constant folding passhttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/80kernelcreation: Translation from SymPy-frontend2024-02-28T10:40:00+01:00Frederik Hennigkernelcreation: Translation from SymPy-frontendThe machinery behind `create_kernel` mapping a kernel expressed in the SymPy-based frontend to the backend needs to be rebuilt. The following primary operations need to be reimplemented or adapted:
- **Freeze AST:** The input Assignmen...The machinery behind `create_kernel` mapping a kernel expressed in the SymPy-based frontend to the backend needs to be rebuilt. The following primary operations need to be reimplemented or adapted:
- **Freeze AST:** The input AssignmentCollection (or whatever container is used) is transformed to the pymbolic-based representation. Output of the freeze should be a pure but still untyped backend-AST containing pymbolic expressions.
- **Type Inference:** The type inference algorithm should compute all missing expression types on the frozen AST. All `Variables` must be replaced by `PsTypedVariable`, all constants replaced by `PsTypedConstant`. After this, the AST is fully typed and must remain so.
- **Loop Nest/ GPU indexing:** Depending on the type of kernel, the AST is wrapped into a loop nest or prepended with a GPU index calculation
- **Optimization**: Various optimizations can be applied. These include:
- Constant folding
- Loop-invariant code motion
- OpenMP parallelization
- Loop transformations (tiling, blocking, splitting)
- Vectorization
After the types are figured out, any operation on the AST must maintain the invariant that the AST is fully and correctly typed.
## Data Structure Correspondence
The following correspondences and translations between front-end and back-end structures exist and might have to be tracked by the translator:
- `sp.Symbol` --(freeze)--> `pb.Variable` --(typing)--> `PsTypedVariable`
- `ps.TypedSymbol` --(freeze)--> `PsTypedVariable`
- `ps.Field` --(freeze)--> `PsLinearizedArray` + `PsTypedVariable`s for pointers and indexing info
## Concept, Components, and Progress
### Iteration Spaces
The kernel's iteration space is modelled using the `IterationSpace` class.
Two variants exist: full and sparse iteration spaces.
The iteration space controls the translation of field accesses to array accesses
and will later be materialized to an index source (e.g. a loop nest) by the platform-specific code generator.
`FullIterationSpace`:
- [x] Creation from ghost layers
- [x] Creation from iteration slice
`SparseIterationSpace`:
- [x] Creation from an index field (requires: struct data types)
### Supported Functions
- [ ] Set up a collection of all supported functions and define their typing behaviour
### FreezeExpressions
The freeze is performed by `freeze.FreezeExpressions`. It inherits from `pb.SympyToPymbolicMapper` and extends it functionality where necessary.
- [x] `Field.Access`:
- [x] Generic and Absolute accesses
- [x] Index field accesses: Require `SparseIterationSpace`
- [x] Buffer accesses: Require inference of buffer indexing
- [ ] Staggered Accesses
- [ ] Exponentials (`sp.Pow`): Expand to multiplications where sensible
- [ ] Functions and function calls: Check if supported and map onto backend function symbols
### Typification
Untyped expressions are typified by `typification.Typifier`.
- [x] Variables: Assign default type from configuration
- [x] Constants: Assign target type from current expression context, or fail if target type is unknown
- [x] Arithmetic expressions: Typify all operands homogenously
- [x] Struct member accesses (`Lookup`): Use struct type
- [x] Array accesses: Typify index expression with `index_dtype` target type
- [x] Functions: Typify according to function type rules (see above *Supported Functions*)
### Platform-Specific Code Generation
The remaining code generation process is controlled by the platform-specific code generator.
All platform-specific code generators shall be subclasses of `platform.Platform` which defines their common interface. They all shall implement:
- [ ] Materialization of the iteration space (sparse and full)
- [x] Basic CPU
- [x] Materialization of functions (map mathematical, in particular transcendental functions, to target-specific implementations)
- [ ] Target-specific optimizations (including vectorization)
- [x] Provide collection of required header files, preprocessor definitions, etc.
The platform instance shall be created from a `TargetSpec` provided by the user.
The main code generation driver shall then call the `Platform` object to finalize code generation.https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/79C Code Printer2024-02-28T09:49:45+01:00Frederik HennigC Code PrinterThe C code printer should be a simple structure-recursive algorithm and not contain any transformation logic, nor should infer or compute any additional information from the AST.
Code printing is currently implemented in `emission.py`. ...The C code printer should be a simple structure-recursive algorithm and not contain any transformation logic, nor should infer or compute any additional information from the AST.
Code printing is currently implemented in `emission.py`. The printer should be kept minimial.
The `CPrinter` class is implemented as a visitor over the AST nodes and calls an instance of pymbolic's [CCodeMapper](https://documen.tician.de/pymbolic/mappers.html#pymbolic.mapper.c_code.CCodeMapper) to print expressions.
An extension of the printer for specific vector instruction sets, etc., should not be necessary: instead, all intrinsics, function calls, etc. should be modelled using pymbolic's `FunctionSymbol` and `Call` nodes.https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/78Type System2024-02-28T09:49:31+01:00Frederik HennigType SystemWe shall extend and refactor the existing type system of pystencils. While the exact structure of the type system still bears discussion, the following features shall be supported:
- The base class `AbstractType` should model a type's ...We shall extend and refactor the existing type system of pystencils. While the exact structure of the type system still bears discussion, the following features shall be supported:
- The base class `AbstractType` should model a type's name and `const` qualifier, such that every type may be `const`.
- Any numerical types have to model their set of legal arithmetic and logical operations.
- Pointers should be general, they shall be able to point to any type.
- A `CustomType` class should be available to model any types outside the scope of pystencils which are managed only through their name (e.g. any types occuring in integration with C++ frameworks)
## Progress
- [x] Scalar Numeric Types: Signed/Unsigned Integers, IEEE-754 floats
- [x] Vector Numeric Types
- [x] Struct typeshttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/77pymbolic extension: Typed Variables, Constants, and LinearizedArray2024-01-27T13:29:42+01:00Frederik Hennigpymbolic extension: Typed Variables, Constants, and LinearizedArrayThe `pymbolic` class hierarchy needs to be extended with a number of typed expressions, in particular for typed variables and constants.
## PsTypedVariable
The `PsTypedVariable` class shall be a direct subclass of the pymbolic `Variabl...The `pymbolic` class hierarchy needs to be extended with a number of typed expressions, in particular for typed variables and constants.
## PsTypedVariable
The `PsTypedVariable` class shall be a direct subclass of the pymbolic `Variable`, annotating a name with a type. In the backend, it takes the position of the old `TypedSymbol`.
## PsTypedConstant
pymbolic allows the injection of arbitrary types for constants, as long as they implement the arithmetic operators. We shall utilize this by introducing `PsTypedConstant` to model constants annotated with types in the backend, to make sure that all operations (e.g. constant folding) respect the type's behaviour.
## Linearized Arrays
To model linearized multi-dimensional arrays, we introduce the class `PsLinearizedArray` to the backend. We may model accesses to such arrays using a sublcass of `pymbolic.Subscript`, linked to a particular array instance.https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/76Abstract Syntax Tree2024-01-27T14:07:33+01:00Frederik HennigAbstract Syntax TreeThe abstract syntax tree is the core data structure of the backend.
It represents the generated C code on a level of abstraction fit for pystencils.
The range of syntax and structure represented by the AST is from the kernel function (up...The abstract syntax tree is the core data structure of the backend.
It represents the generated C code on a level of abstraction fit for pystencils.
The range of syntax and structure represented by the AST is from the kernel function (upper limit) to just above the arithmetic-logical expressions (lower limit). Above that, code generation is the business of whatever framework pystencils is embedded in. Below, we use `pymbolic`.
## Class Hierarchy and Syntax Modelling
The base class of the AST nodes shall be `PsAstNode`. Its primary tasks are:
- Manage the branching structure
- Manage custom metadata
There shall be a dedicated class for each required syntactic structure, including:
- *Loops:* We model increment-type loops by `PsLoop`
- *Expressions:* Expressions are modelled using pymbolic. Each pymbolic expression in the AST is wrapped in the `PsExpression` leaf node or its subclasses.
## Typing in Expressions
In a well-formed AST, all pymbolic expressions must be fully typed; they may contain no bare `Variable`s and no bare constants, but only their typed variants `PsTypedVariable` and `PsTypedConstants` (see pycodegen/pystencils#77).
## Correspondence to frontend data structures and metadata
The AST is made up of a fixed set of backend data structures, and shall contain no frontend (e.g. SymPy-related) data structures in its primary structure. However, mappings to front-end structures might be managed within the AST metadata.
A metadata dict shall exist on each AST node for any frontend to store arbitrary data in. The backend shall not access that metadata.
## Visitors
As most algorithms on the AST will follow the visitor pattern, a type-based visitor dispatcher is provided to simplify the implementation of recursive visitor-type algorithms.https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/75Modernize pystencils' dev environment2024-01-09T14:10:28+01:00Frederik HennigModernize pystencils' dev environmentWe should modernize the development environment of pystencils to latest Python practice. This includes:
### pyproject.toml
We should migrate from the `setup.py` paradigm of `setuptools` to the now-standard `pyproject.toml` ([PEP 518](h...We should modernize the development environment of pystencils to latest Python practice. This includes:
### pyproject.toml
We should migrate from the `setup.py` paradigm of `setuptools` to the now-standard `pyproject.toml` ([PEP 518](https://peps.python.org/pep-0518/)) for the basic build system configuration.
This way, we can enjoy all the helpful tools that now base themselves on `pyproject.toml` (see 'Dependency Management' below).
Still, some tool-specific stuff may have to remain in `setup.py`.
### Dependency Management
Currently, as far as I am aware, setup of a dev environment for pystencils depends on `requirements.txt` files flying around wildly.
To consolidate and clearly define a uniform development environment. we should instead introduce a packaging and dependency manager into the project - I'd recommend [pdm](https://pdm-project.org/latest/). This way, all developers would get the exactly same environment, with exactly the same versions of all required dependencies - including dev and build dependencies like `flake8`, `sphinx`, etc.
### Type Checking
pystencils has become a vast package with many moving parts, and as a generator of exectuable code, a high level of correctness is expected of it. While extensive unit tests are a necessary tool to achieve correctness, they can never be entirely watertight. Being written in Python, users and developers of pystencils enjoy great flexibility due to Python's dynamic type system. However, that same type system may also permit a much larger number of (potential) bugs to go unnoticed for a very long time.
To alleviate this issue, Python itself has been gradually introducing and improving its system of type hints, which although are not mandatory
nor do they affect the code in any way by themselves. However, type checkers like [mypy](https://www.mypy-lang.org/) have been developed on top of that to statically check the types in Python code.
In particular in the context of pycodegen/pystencils#73, we should gradually introduce thorough static type checking into pystencils.
This will help to make the code more robust and achieve a higher level of correctness a-priori. Types can be checked on developer's machines (e.g. as a hook to `git add`/`git commit`) and in the CI (much like linting with `flake8`).https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/74Constness in generated code2024-03-27T18:23:27+01:00Frederik HennigConstness in generated codeThe way pystencils determines constness and placement of `const` keywords is very intransparent and at times misleading.
Things that should be const are often printed non-const. While we may expect compilers to detect constness by themse...The way pystencils determines constness and placement of `const` keywords is very intransparent and at times misleading.
Things that should be const are often printed non-const. While we may expect compilers to detect constness by themselves, this
makes integration into other code frameworks more tedious, and still may impact performance.
Luckily, so far, I have not observed the opposite (non-const values printed const) which would just not compile.
## Constness
Constness is introduced in the following places (maybe I've missed something):
- In the type system:
- `BasicType` and `StructType`: An object type may be `const`-qualified. That is how it should be in a C code generator.
- `PointerType`: A pointer may be `const`-qualified, and its pointed-to type may also be; so theoretically, all four possible combinations of constness on pointers can be realized. This does not hold for the recently introduced double pointers (pycodegen/pystencils!356), though; see below.
- In the AST: `SympyAssignment` has a member `is_const` for constant declarations.
While it is perfectly sensible to const-qualify types, annotating assignments with context has the potential for vast confusions; what if the type of the LHS is non-const? How to print it if it is const?
## Problems
### Field Access Resolution
In `transformations.py` ([here](https://i10git.cs.fau.de/pycodegen/pystencils/-/blob/master/pystencils/transformations.py#L557)), the data pointer for a field access is created with `const=True` if the field is read-only; however this creates a const pointer, not a pointer to const. The pointed-to data type is still non-const.
### Code Printer
The code printer handles const `SympyAssignment`s ([here](https://i10git.cs.fau.de/pycodegen/pystencils/-/blob/master/pystencils/backends/cbackend.py#L273)) in a fashion that is clearly problematic: The LHS type is printed, and then all occurences of `const` are removed from it by string operations. Then a leading `const` is added.
This breaks down in the presence of pointers (especially now, with the new double pointers): `const` may occur more than once in a pointer type. Also, if the declaration LHS is of pointer type, the `const` keyword must not be added to the left, but to the right of the type string.
## Solutions
Constness should exclusively be a part of the type, and the type system should respect it.
I've tried several avenues of fixing this, without success; even though constness only occurs at very few places in the code, the way they are spread across the code makes changing them extremely challenging.
The constness issue should enter consideration of the design of the new backend (pycodegen/pystencils#73), where it can then be solved as a 'by-the-way', simply by clean integration of constness in the type system.Release 2.0Frederik HennigFrederik Hennighttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/73pystencils Backend Rework2024-03-20T10:53:56+01:00Frederik Hennigpystencils Backend ReworkThe code generation backend of pystencils is due for a major overhaul. This issue is meant to track the efforts in this direction.
Development branch: `pystencils/backend-rework`
The various sub-tasks of this project are documented usi...The code generation backend of pystencils is due for a major overhaul. This issue is meant to track the efforts in this direction.
Development branch: `pystencils/backend-rework`
The various sub-tasks of this project are documented using the Tasks below.
Documentation for this branch is currently served here: https://da15siwa.pages.i10git.cs.fau.de/dev-docs/pystencils-nbackend/Release 2.0Frederik HennigFrederik Hennighttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/72Divisions are printed using `pow`2023-09-28T14:49:11+02:00Daniel BauerDivisions are printed using `pow`# Description
pystencils prints divisions like `1/x` as `pow(x, -1.0)`.
The floating point `pow` function is of course undesirable due to performance concerns.
It looks like pystencils intends to [print powers with small integer expon...# Description
pystencils prints divisions like `1/x` as `pow(x, -1.0)`.
The floating point `pow` function is of course undesirable due to performance concerns.
It looks like pystencils intends to [print powers with small integer exponent using multiplications and divisions](https://i10git.cs.fau.de/pycodegen/pystencils/-/blob/master/pystencils/backends/cbackend.py#L447-450).
However, the [types of powers are collated between the base and exponent](https://i10git.cs.fau.de/pycodegen/pystencils/-/blob/master/pystencils/typing/leaf_typing.py#L215-224).
Note that sympy converts divisions to powers automatically.
# MWE
```python
import pystencils as ps
from pystencils import CreateKernelConfig
from pystencils.astnodes import Block, KernelFunction, SympyAssignment
from sympy.abc import x, y
equ = SympyAssignment(y, 1/x)
typed_equ = ps.typing.transformations.add_types(equ, CreateKernelConfig())
print(typed_equ)
kernel = KernelFunction(
Block([typed_equ]),
ps.Target.CPU,
ps.Backend.C,
ps.cpu.cpujit.make_python_function,
None,
)
code = ps.get_code_str(kernel)
print(code)
```
## Actual output
```c
y ← x**CastFunc(-1, double)
FUNC_PREFIX void kernel(double x)
{
const double y = pow(x, -1.0);
}
```
## Expected output
```c
y ← x**CastFunc(-1, int)
FUNC_PREFIX void kernel(double x)
{
const double y = 1.0 / x;
}
```https://i10git.cs.fau.de/pycodegen/pystencils/-/issues/71Installation fails for Python 3.112023-07-21T11:59:59+02:00Daniel BauerInstallation fails for Python 3.11Trying to install on Python 3.11 gives the error
```
gcc -Wsign-compare -DNDEBUG -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror...Trying to install on Python 3.11 gives the error
```
gcc -Wsign-compare -DNDEBUG -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -DOPENSSL_LOAD_CONF -fwrapv -fno-semantic-interposition -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor/ -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor/ -fPIC -I/usr/include/python3.11 -c pystencils/boundaries/createindexlistcython.c -o build/temp.linux-x86_64-cpython-311/pystencils/boundaries/createindexlistcython.o
pystencils/boundaries/createindexlistcython.c:211:12: fatal error: longintrepr.h: No such file or directory
211 | #include "longintrepr.h"
| ^~~~~~~~~~~~~~~
compilation terminated.
error: command '/usr/bin/gcc' failed with exit code 1
```
Seems like every Python project using Cython eventually runs into this.
I *think* using a recent Cython version fixes the problem.
See https://github.com/cython/cython/issues/4461 for more information.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/70pyCUDA vs CuPy2023-06-22T17:26:18+02:00Markus HolzerpyCUDA vs CuPyShould we replace [PyCuda](https://documen.tician.de/pycuda/) with [CuPy](https://cupy.dev/)?
Advantages of [CuPy](https://cupy.dev/):
- AMD support
- probably higher maintained due to NVIDIA support
- SciPy compatible.Should we replace [PyCuda](https://documen.tician.de/pycuda/) with [CuPy](https://cupy.dev/)?
Advantages of [CuPy](https://cupy.dev/):
- AMD support
- probably higher maintained due to NVIDIA support
- SciPy compatible.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/issues/69sync data to GPU when loade2023-06-22T17:26:18+02:00Markus Holzersync data to GPU when loadeCalling dh.load_all does not sync the GPU arrays. This is not user friendlyCalling dh.load_all does not sync the GPU arrays. This is not user friendlyMarkus HolzerMarkus Holzer