# ArrayFire vs AbstractArray performance and future in julia

**URL:** <https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533>\
**Category:** Machine Learning\
**Created:** [May 4, 2021, 5:08pm UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533 "2021-05-04T17:08:49Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![DoktorMike](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/doktormike/32/2736_2.png) [@DoktorMike](https://discourse.julialang.org/u/DoktorMike)\
**Post date:** [May 4, 2021, 5:08pm UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533/1 "2021-05-04T17:08:49Z")

</div>

So I recently ran into ArrayFire and it’s Julia wrapper ArrayFire.jl and was impressed by the performance benchmark. I have not tried it myself and I was wondering if anyone has made any experiments with it and if it’s compatible with Flux, DifferentialEquations etc.?

---

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [May 4, 2021, 5:57pm UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533/2 "2021-05-04T17:57:03Z")

</div>

AFAIK it is not, mostly because of operator coverage. I think that’s partially a reflection of how little non-CUDA GPU compute happens in ML (and what does happen, is probably covered by AMDGPU.jl or oneAPI.jl better)

---

<div class="post-metadata">

**Author:** ![DoktorMike](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/doktormike/32/2736_2.png) [@DoktorMike](https://discourse.julialang.org/u/DoktorMike)\
**Post date:** [May 4, 2021, 6:53pm UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533/3 "2021-05-04T18:53:06Z")

</div>

Thanks for the response. What sparked my interest in this is FAIRs latest library flashlight 🔦 [Flashlight: Fast and flexible machine learning in C++](https://ai.facebook.com/blog/flashlight-fast-and-flexible-machine-learning-in-c-plus-plus/) which builds on ArrayFire as a tensor library. These guys are usually all about performance which is why I assumed that there’s something to be said about ArrayFire. I still live in a world where i hope that the models i make can rely on a backend that always chooses the right available hardware for the job. 😂

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [May 5, 2021, 6:37am UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533/4 "2021-05-05T06:37:46Z")

</div>

People have used it with DifferentialEquations.jl successfully (you can search this Discourse for many answers that do it), but usually CUDA.jl is going to be better because of how it can generate fused kernels.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [May 5, 2021, 6:46am UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533/5 "2021-05-05T06:46:05Z")

</div>

I’m a bit confused about the title. Rather than `AbstractArray` perhaps you mean `Array`?

`AFArray` is an `AbstractArray` after all:  
[https://github.com/JuliaGPU/ArrayFire.jl/blob/master/src/array.jl#L1](https://github.com/JuliaGPU/ArrayFire.jl/blob/master/src/array.jl#L1)

---

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [May 5, 2021, 4:48pm UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533/6 "2021-05-05T16:48:44Z")

</div>

Seems like even Flashlight uses MKL-DNN and CUDA for many of its backend ops. ArrayFire proper is used for basic ops and OpenCL support only. I’m not sure anyone would object to resuscitating the Julia package, but trying to fit it in the current GPUArray interface would likely be a challenge.

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [May 5, 2021, 5:14pm UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533/7 "2021-05-05T17:14:28Z")

</div>

ArrayFire was a great way to bootstrap Julia’s GPU compute support, but it is not what you want to use for a mature, flexible language like Julia in the long term. Since Julia+GPUCompiler can generate arbitrary (fused) kernels with competitive performance to CUDA C++/ROCm HIP, there’s not really a good reason to use ArrayFire (unless your hardware isn’t supported by CUDA.jl/AMDGPU.jl/oneAPI.jl).

If you want to reach more people who have unsupported GPUs or use Windows with an AMD GPU, the better approach is to consider reviving CLArrays.jl (warning: not a small or easy task) and making it fully GPUArrays-compatible.

---

<div class="post-metadata">

**Author:** ![DoktorMike](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/doktormike/32/2736_2.png) [@DoktorMike](https://discourse.julialang.org/u/DoktorMike)\
**Post date:** [May 5, 2021, 6:00pm UTC](https://discourse.julialang.org/t/arrayfire-vs-abstractarray-performance-and-future-in-julia/60533/8 "2021-05-05T18:00:34Z")

</div>

I was not aware of this. Thanks for pointing it out.