Should scippneutron stay a C++ library, or move to Python-only?

[SimonHeybrock]

Since this comes up periodically I thought I would gather the arguments here. I am not arguing for either right now, this is mainly for future reference.

Reasons to change to Python-only

• Simpler CI and packaging.
• Easier to release.
• Does not break with many scipp releases that are ABI incompatible.
• Easier for users or downstream packages (ess) that do not need Mantid.

Reasons to keep the C++ dependence on scipp

• Once we make the change it will be hard to go back.
• Without an active "user" of the C++ API of scipp we may gradually (and unknowingly) making it unusable.
• Potential performance needs for compound operations, in particular in coordinate transformations.

Coordinate transformations

Regarding coordinate transformations, I want to analyze a couple of cases. The relevant ones are those where more than one operation with a "large" operand are needed. I am excluding things such as two_theta. Those may be large when gravity-correction is used, but that is a special case and has less relevance.

tof -> energy

https://github.com/scipp/scippneutron/blob/31b2e6541d0d40ce11ec40335e6ddf315f0cfe93/src/scippneutron/core/conversions.py#L102-L105

• Currently written with 2 large allocations.
• Can be rewritten in Python to 1 large allocation + 2 ops, but a bit tricky.
• Could be a single large allocation + 1 op if scipp provided an 1/a**2 operation.
• Could be a single large allocation if scipp provided an a/b**2 operation.

tof -> energy transfer direct

https://github.com/scipp/scippneutron/blob/31b2e6541d0d40ce11ec40335e6ddf315f0cfe93/src/scippneutron/core/conversions.py#L108-L116

• Currently written with 6 large allocations.
• Can be rewritten in Python to 4 large allocations + 3 ops
• Could be 4 large allocations if scipp provided an 1/a**2 and inplace fmadd operation.
• Can get to less than 4 allocations only with some sort of "inplace" where operation.
• Could be a single allocation (op) with dedicated compiled transform.

[SimonHeybrock]

We may consider reviving scipp/scipp#1898 for this. So far we have not done a performance test with this though, so it is not clear if it would provide the required speed.

[nvaytet]

Do we really expect these unit conversions to be the bottleneck of the workflows? I guess this is what you meant by "I want to analyze a couple of cases". If we consider this in the wider context of the entire workflow, it may not be so important if this step is slower, if other parts of the workflow take longer anyway?

The memory consideration (all the extra allocations) is probably the more important one. Do I understand correctly that a custom Numba kernel could allow to do this with only a single allocation? If so, then maybe it would be a good alternative even if the conversion is slower than native C++?

[SimonHeybrock]

Do we really expect these unit conversions to be the bottleneck of the workflows?

Probably not, but I think it would definitely lower the point at which performance becomes an annoyance to users.

[jl-wynen]

Do I understand correctly that a custom Numba kernel could allow to do this with only a single allocation?

Yes. Only one allocaction on our side. No idea what numba does, though. But it would definitely reduce the memory requirements of coordinate transforms. However, we might be able to express them in such a way that that is a non-issue. See Simon's older comment.

[SimonHeybrock]

I think to support coming to a decision here we should make a benchmark, comparing (for our most complex conversion step, probably inelastic scattering?):

• performance with direct compilation of the kernel
• performance with a generic function-pointer kernel (the compiler will not be able to optimize this very much), for the Numba case.

[SimonHeybrock]

I'll close this, as the ongoing release should address this (making scippneutron Python-only).