Add Numba void* -> typed-pointer intrinsics and tests #804
Conversation
create_voidptr_to_dtype_ptr_caster to bitcast void* to typed pointer. Provide convenience casters for common primitives: float64, float32, int32, int64. Add unit tests in test_numba_custom_data.py exercising the new casters: Tests cover basic float/double and int pointer casting and multi-parameter usage.
| b = numba.carray(b_, (1,), dtype=np.float64) | ||
| fptr = voidptr_to_float64_ptr(custom_data) | ||
| iptr = voidptr_to_int32_ptr(custom_data) | ||
| scale = fptr[0] |
There was a problem hiding this comment.
Bit hairy, in the future we should look and see if we can reinterpret the struct with its fields and let numba/llvm handle the offsets for us.
There was a problem hiding this comment.
I made some attempts but have not been able to find a nice and robust way yet. I tried with record caster.
…FCx utils ffcx: annotate create_voidptr_to_dtype_ptr_caster with type hints and clarify when void* casts are required. - Add docstring explaining use cases for voidptr cast (custom_data in UFCx kernels). - Validate input types early and raise clear TypingError on invalid source types.
|
I'm not convinced that this is code we want to support. One can write really good (and compact) assemblers in Numba if one doesn't use the UFCx interface. Allocated arrays in Numba are dynamically allocated and therefore go on the heap rather than the stack, which is a performance problem. This doesn't mean we shouldn't support Numba for simple problems which require virtually no extra code, but we should really keep it very simple. |
|
@garth-wells In this PR, the functions are only intended as test scaffolding to validate passing custom_data through to the integral kernel (in support of the dolfinx PR [FEniCS/dolfinx/pull/4013] ). They are not meant to be performant or to establish a supported Numba-based assembly path. I initially had the relevant intrinsics embedded directly in the dolfinx test that checks custom_data passing, but moved them into FFCx to follow the existing pattern (other intrinsics live in FFCx as well). If you’d prefer a different testing approach that avoids introducing even minimal Numba-side code, I’m very open to suggestions. The key requirement is simply having a reliable test for the custom_data passing. The longer-term goal here is to use custom_data for runtime quadrature rules; this PR is only about ensuring the mechanism is correctly wired and testable. |
|
I think @garth-wells is just talking about making this new method private. Then there is no future obligation on us maintain the API stability or even keep the code around. Or it could go back in the DOLFINx tests (sorry!). |
|
I don't follow the heap vs stack argument here - the data passed by through this new voidptr is not allocated by numba. |
The point is that Numba kernels that follow the UFCx interface are not performant. We shouldn't add tooling to support an interface that can't give good performance. |
This PR adds a small, reliable Numba intrinsic factory for casting void* (FFCx custom_data) to typed C pointers and provides convenience casters for common primitive types, plus unit tests exercising those casters. This PR is relevant for custom_data functionality in dolfinx https://github.com/FEniCS/dolfinx/pull/4013.