# Supporting several targets in library code **URL:** \ **Category:** Numba\ **Created:** [August 11, 2022, 7:11am UTC](https://numba.discourse.group/t/supporting-several-targets-in-library-code/1496 "2022-08-11T07:11:22Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![astrojuanlu](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/astrojuanlu/32/138_2.png) [@astrojuanlu](https://numba.discourse.group/u/astrojuanlu)\ **Post date:** [August 11, 2022, 7:11am UTC](https://numba.discourse.group/t/supporting-several-targets-in-library-code/1496/1 "2022-08-11T07:11:22Z")
As part of [a NumFOCUS Small Development Grant that we got awarded in poliastro](https://github.com/poliastro/documents/blob/master/numfocus-sdg-2021-r3.md), @s-m-e has been doing a lot of exploration around accelerating orbit propagation for many orbits and many epochs. One of the things we noticed is that, even though [“in general it is recommended not to pass any explicit signature to `@jit`”](https://github.com/numba/numba/issues/1691#issuecomment-181365121) (unsure if this still holds 6 years later?), it’s unclear if the type inference of the `parallel` and `cuda` targets are on par with the `cpu` target. If that’s the case, if we are a library and want to support several targets at the same time, we have to either - Specify the types on the signature, which is not recommended for the `cpu` target, or - Not specify the types, which might give problems for the `parallel` and `cuda` targets. There’s another possibility, which is that we are wrong with our assessment and all targets have equal type inference capabilities and we can let numba do the work. What do you folks advise us to do? ---
**Author:** ![gmarkall](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/gmarkall/32/42_2.png) [@gmarkall](https://numba.discourse.group/u/gmarkall)\ **Post date:** [August 12, 2022, 9:03am UTC](https://numba.discourse.group/t/supporting-several-targets-in-library-code/1496/2 "2022-08-12T09:03:38Z")
The targets have equal type inference capabilities, but the impact of the typing on the targets differs. CUDA kernels are extremely sensitive to register usage, so typing everything as 64-bit types has little impact on the CPU variant of a function, but a big impact on the CUDA variant - the performance improvements from providing signatures that I understand @s-m-e has observed from providing signatures is likely down to this. The general advice is not to provide signatures - however, I think your use case is a more advanced one for which I’d deviate from the standard advice, and instead I’d suggest explicitly providing signatures. Providing signatures for the CPU target isn’t an issue per se - it’s just that beginners get it wrong a lot of the time and it is not necessary in many cases unlike your particular situation - so we generally advise against doing it - but, there does come a point at which it makes sense to do so which in my opinion you have reached with this Poliastro work. ---
**Author:** ![gmarkall](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/gmarkall/32/42_2.png) [@gmarkall](https://numba.discourse.group/u/gmarkall)\ **Post date:** [August 12, 2022, 9:04am UTC](https://numba.discourse.group/t/supporting-several-targets-in-library-code/1496/3 "2022-08-12T09:04:23Z")
Also, congratuations on being awarded the NumFOCUS Small Development Grant! 🎉 ---
**Author:** ![astrojuanlu](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/astrojuanlu/32/138_2.png) [@astrojuanlu](https://numba.discourse.group/u/astrojuanlu)\ **Post date:** [August 12, 2022, 9:20am UTC](https://numba.discourse.group/t/supporting-several-targets-in-library-code/1496/4 "2022-08-12T09:20:38Z")
Thanks a lot for the detailed answer @gmarkall! My main concern has always been losing generality by using `float64` instead of letting numba figure out the types, getting errors if someone accidentally passes an integer, etc. But these are minor things that can be compensated by other means. ---
**Author:** ![s-m-e](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/s-m-e/32/536_2.png) [@s-m-e](https://numba.discourse.group/u/s-m-e)\ **Post date:** [August 12, 2022, 10:38am UTC](https://numba.discourse.group/t/supporting-several-targets-in-library-code/1496/5 "2022-08-12T10:38:23Z")
> [@gmarkall](#): > > the performance improvements from providing signatures that I understand @s-m-e has observed from providing signatures is likely down to this. It’s partially performance, yes, but also failures of the compile process itself. If I do not provide signatures for the `parallel` and `cuda` targets, the JIT will spit out various fun tracebacks, in some cases not even related to types at all. The “fix”, from experience, is to provide types and suddenly the JIT is happy again. I ran into this before, on smaller scales, but big time in poliastro. I can provide a few examples if I find the time. I distinctly remember three tracebacks I was seeing frequently. My impression was that thanks to the (automatic) parallelization that happens in those cases for both the CPU and GPU the code generation differs enough to make the type interference fail. At least this how I pictured it. ---
**Author:** ![gmarkall](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/gmarkall/32/42_2.png) [@gmarkall](https://numba.discourse.group/u/gmarkall)\ **Post date:** [August 12, 2022, 11:07am UTC](https://numba.discourse.group/t/supporting-several-targets-in-library-code/1496/6 "2022-08-12T11:07:26Z")
Were any of these for the `@guvectorize` decorator? That still requires signatures for the CUDA target (I don’t know if it’s also needed for the parallel one).