NBEP for @cfunc

[pitrou]

No description provided.

[seibert]

Transcribing my review comments from chat here:

• Is it possible to add support for casting a JIT class to/from a void * pointer? Not a high priority, so maybe we don't want to clutter the first implementation with this.
• Otherwise, I like the ctypes object being a separate attribute, so that we can add a CFFI object in the future if that becomes important.
• Can you show how @cfunc would be used with ahead of time compilation?

[codecov-io]

Current coverage is 73.19%

Merging #1841 into master will decrease coverage by -14.31%

1. 15 files (not in diff) in ...umba/hsa/tests/hsapy were created. more
2. 3 files (not in diff) in ...mba/hsa/tests/hsadrv were created. more
3. 1 files (not in diff) in numba/hsa/tests were created. more
4. 5 files (not in diff) in numba/hsa/hsadrv were created. more
5. 5 files (not in diff) in numba/hsa/hlc were created. more
6. 16 files (not in diff) in numba/hsa were created. more
7. 2 files (not in diff) in ...ba/cuda/tests/nocuda were created. more
8. 3 files (not in diff) in ...a/cuda/tests/cudasim were created. more
9. 57 files (not in diff) in ...ba/cuda/tests/cudapy were created. more
10. 19 files (not in diff) in ...a/cuda/tests/cudadrv were created. more

@@             master      #1841   diff @@
==========================================
  Files           288        461     +173   
  Lines         51589      62692   +11103   
  Methods           0          0            
  Messages          0          0            
  Branches       5340       6244     +904   
==========================================
+ Hits          45144      45887     +743   
- Misses         5535      15888   +10353   
- Partials        910        917       +7   

Powered by Codecov. Last updated by 965a794...34d0436

[izaid]

DyND is very interested in this as well, so putting a comment here so I get pinged.

[pitrou]

Is it possible to add support for casting a JIT class to/from a void * pointer?

How would foreign C code interpret the NRT-allocated JIT class?

I like the ctypes object being a separate attribute, so that we can add a CFFI object in the future if that becomes important

Yes (though I'm not sure the same would be possible with cffi).

Can you show how @cfunc would be used with ahead of time compilation?

Actually, I had not envisioned that possibility. Implementing it would need doing something like CFFI, i.e. compiling the "C function object" as a member of a C extension (rather than a plain Python class inside Numba).

[seibert]

The void * pointer case would be for APIs where foreign C code does not every try to dereference the pointer, but simply passes it back to the callback as way for the callback to retain state between calls. I don't think it is particularly important at the moment, but I wanted to raise the issue.

As for the ahead-of-time compilation case: Couldn't we handle @cfunc the same as @jit for ahead of time compilation? We're still not going to support using the C function outside of the Python interpreter (yet).

[pitrou]

Couldn't we handle @cfunc the same as @jit for ahead of time compilation?

Well, @jit and AOT compilation are quite separate things currently (both API-wise and implementation-wise) :-)

The void * pointer case would be for APIs where foreign C code does not every try to dereference the pointer, but simply passes it back to the callback as way for the callback to retain state between calls.

Oh, I see, I hadn't thought about that. That's an interesting case. There are two sides to it:

• on the Python front, allow the user to take the address (as a ctypes object?) of a jitclass instance
• on the Numba front, allow casting from types.voidptr to any jitclass instance type

[seibert]

I think we can hold the AOT compilation question for after the first implementation.

One additional thing we do want to support (to minimize surprise) is calling @cfunc functions from nopython mode, similar to how we can call ctypes functions now.

[gdementen]

Can you use both @cfunc and @jit on the same function? To get the equivalent of cpdef in cython?

[seibert]

We had not planned to allow @cfunc and @jit to be used on the same function because C signatures (which frequently require array shape information to be passed separately from the data pointer) are not going to be easily callable from Python.

I expect that in situations where you want to call the function from both an external C API and from Python, it would make sense to follow a pattern where the @jit function is the real calculation and the @cfunc is just a wrapper that creates the appropriate array views:

@jit
def mean_square_error(params, x, obs_y):
    c0, c1 = params
    sq_error = 0.0
    for i in range(x.size):
        sq_error += ((c0 + c1 * x[i]) - obs_y[i])**2

    return sq_error / x.size

@cfunc(float64(intp, CPointer(float64), intp, CPointer(float64), CPointer(float64)))
def mean_square_error_callback(nparams, params, npoints, x, obs_y):
    params_array = carray(params, (nparams,))
    x_array = carray(x, (npoints,))
    obs_y_array = carray(obs_y, (npoints,))

    return mean_square_error(params_array, x_array, obs_y_array)

It is quite possible that LLVM will even fuse these functions together during optimization.

[gdementen]

Good point for array arguments, but for simple "elementwise" functions, like "integrand" in the proposal text, this would avoid having to define silly boilerplate code, though I admit this is not a frequent use case for me.

This is almost unrelated to this proposal (*) but CPointer(type) looks ugly to me/inconsistent with "voidptr". I would prefer "cptr", "ptr" or even "cpointer".

(*) I mention it here because it is the first time I see it.

[seibert]

OK, going to merge this now that the initial implementation is basically done.

[izaid]

At what point should I attempt to do something with this and DyND? Is that point now?

I'd be happy to try and update our Numba bindings, and give feedback if that's the case.

[seibert]

I'd wait for the Numba 0.26 release in a few weeks. The PR implementing carray() and farray() is still going through code review. Once it is merged, we'll likely start the release process.

[seibert]

If you want to be super bleeding edge, you could build from #1871