kaushikcfd / feinsum Goto Github PK

This would be really significant for memory-bound batched einsums as this opens up the possibility of sharing operands via lower latency address spaces.

The following array packages come to mind:

• JAX
• NumPy

Assuming the code generator follows a naming scheme for specifying transformations is brittle.

Causing compilation to trigger multiple times i.e. ~40% of the time spent in a run is redundant.

https://github.com/illinois-ceesd/mirgecom/blob/main/.rtd-env-py3.yml provides a good example.

We should implement our own search-space exploration techniques.

This should allow us to handle operands that depend on multiple uses.

Checks like:

• Does transform_id exist under tuning/impls/.
• Possibly run some timing tests to verify the reported timings (at least on a subset of a "new" values)

• A canonicalization routine is an attractive option.
• The canonicalization should respect both: the re-arrangements at the indexing expression level and the ordering in the sequence of the einstein summations.

Easier debugging + significantly improves the legibility of the DB.

Suggested by @inducer.

cl.Context does NOT define the device on which the transformation will be run.

With the additional assumption that all the operands are non-negative, the transformations (both algebraic and loop) would be sound (I think) to translate from their Einstein summation equivalents.