# Deployment questions: AOT and Portability

**URL:** <https://discourse.julialang.org/t/deployment-questions-aot-and-portability/7262>\
**Category:** GPU\
**Tags:** gpu\
**Created:** [November 23, 2017, 6:04am UTC](https://discourse.julialang.org/t/deployment-questions-aot-and-portability/7262 "2017-11-23T06:04:04Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![drjoke](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/drjoke/32/23562_2.png) [@drjoke](https://discourse.julialang.org/u/drjoke)\
**Post date:** [November 23, 2017, 6:04am UTC](https://discourse.julialang.org/t/deployment-questions-aot-and-portability/7262/1 "2017-11-23T06:04:04Z")

</div>

AOT: Is it possible to enable AOT compilation? It takes around 10 seconds to compile the kernel. Compilation happens every time even when I rarely change the kernel.

Portability: When I run the code on a machine without CUDA, an error occurs at the first inclusion of “using CUDAdrv, CUDAnative” . Currently my strategy is to keep CUDANative code in separate files and only include them when the machine has CUDA. Is there a better elegant strategy to have the code run on a machine with and without CUDA other than selective inclusion of source files.

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [November 23, 2017, 7:09am UTC](https://discourse.julialang.org/t/deployment-questions-aot-and-portability/7262/2 "2017-11-23T07:09:16Z")

</div>

> [@drjoke](#):
>
> It takes around 10 seconds to compile the kernel.

That shouldn’t be the case. Yes, the _first_ compilation takes a while, but that is mainly due to the CUDAnative.jl and LLVM.jl packages getting compiled to native code. Future developments on the Julia compiler should improve this.

Subsequent compilation of new or modified kernels should take less than 1 second, depending on the complexity.

> [@drjoke](#):
>
> Portability: When I run the code on a machine without CUDA, an error occurs at the first inclusion of “using CUDAdrv, CUDAnative” .

Yes, conditional modules are a weak point of the package infrastructure. @MikeInnes has also been dealing with this, I think what we do in general is have conditional code depending on whether CUDAnative is installed (by checking `Pkg.installed`) and a device is available, checked at package build time setting a global flag. That way, you avoid nasty errors by having CUDAnative listed in REQUIRE but throwing a fit during Pkg.build.

---

<div class="post-metadata">

**Author:** ![mauro3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mauro3/32/292_2.png) [@mauro3](https://discourse.julialang.org/u/mauro3)\
**Post date:** [November 23, 2017, 7:21am UTC](https://discourse.julialang.org/t/deployment-questions-aot-and-portability/7262/3 "2017-11-23T07:21:47Z")

</div>

I’m not sure whether this applies here, but checkout Revise.jl [[ANN] Higher productivity (fewer Julia restarts) with Revise.jl](https://discourse.julialang.org/t/ann-higher-productivity-fewer-julia-restarts-with-revise-jl/4564).

---

<div class="post-metadata">

**Author:** ![MikeInnes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikeinnes/32/3656_2.png) [@MikeInnes](https://discourse.julialang.org/u/MikeInnes)\
**Post date:** [November 23, 2017, 12:18pm UTC](https://discourse.julialang.org/t/deployment-questions-aot-and-portability/7262/4 "2017-11-23T12:18:54Z")

</div>

RE portability: As far as possible, you should just deal with `AbstractArray`s. If you do need to special-case the GPU, e.g. with a custom kernel, you can handle that with Requires.jl:

```julia
@require CuArrays begin
  using CuArrays, CUDAnative
  # overload some functions for CuArray
end

```

The GPU workflow for your library will look something like:

```julia
using Foo, CuArrays

my_data = cu(my_data)
Foo.excellent_computations(my_data)

```

This is a pretty reasonable way to ask for GPU support, and it will just work if you do things as above – as well as being much more robust than things like checking `Pkg.installed` at compile time.

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [November 23, 2017, 12:36pm UTC](https://discourse.julialang.org/t/deployment-questions-aot-and-portability/7262/5 "2017-11-23T12:36:11Z")

</div>

> [@MikeInnes](#):
>
> As far as possible, you should just deal with AbstractArrays. If you do need to special-case the GPU

@drjoke seems to be using CUDAdrv/CUDAnative explicitly, not an array-based interface. But yeah, if that’s possible it is a better approach.

---

<div class="post-metadata">

**Author:** ![sdanisch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sdanisch/32/1406_2.png) [@sdanisch](https://discourse.julialang.org/u/sdanisch)\
**Post date:** [November 23, 2017, 12:49pm UTC](https://discourse.julialang.org/t/deployment-questions-aot-and-portability/7262/6 "2017-11-23T12:49:41Z")

</div>

You can also write your code against [GPUArrays](https://github.com/JuliaGPU/GPUArrays.jl) to circumvent this issue, since it’s hardware Independent, but still allows you to write GPU kernels.

See: [Writing extendable and hardware agnostic GPU libraries | by Simon Danisch | techburst](https://medium.com/@sdanisch/writing-extendable-and-hardware-agnostic-gpu-libraries-b21c145a8dad)