GPU support

[bhack]

I want to start this topic just to discuss how GPU support could be introduced in the library.

• SyCL (lack of [full opensource compiler support but great c++ integration. Low level optimizzation limits for kernels?).
• CLCUDAPI (header only helper)
• OCCA
• Boost Compute (lack of cuda support)

/cc @Randl @edgarriba

[bhack]

See also section 3.4 in https://github.com/kokkos/array_ref/blob/master/proposals/P0331.rst

[feliwir]

Would be interesting, indeed

[SylvainCorlay]

Note that we now have strong simd support for broadcasting and a number of other use cases, based on the xsimd project.

[feliwir]

@SylvainCorlay SIMD is good and all, but the performance is not comparable to GPU acceleration. Especially for deep learning applications it makes a lot of sense to use this kind of acceleration. Since this library uses numpy as an api orientation i recommend looking at pytorch, which has similiar goals but uses GPU acceleration.

[SylvainCorlay]

GPU is in scope and in the roadmap. I meamt that the work done for simd actually paved the way since a lot of the required logic in xtensor is the same.

Note that frameworks like pytorch don't implement compile-time loop unfolding like xtensor does which can make xtensor faster in complex expressions.

[feliwir]

awesome, thanks for letting me know. How are you planning to implement it? Are contributions possible?

[AuroraDysis]

I recommend use MAGMA as the backend to support both GPU and CPU

[ktnyt]

Just wondering if there are any updates on the topic. I'd love to make contributions where possible!

[wolfv]

We have GPU support on our roadmap for 2019. However, we're not yet sure how to do it concretely! So any input is highly appreciated.
And of course, contributions are very welcome!

The thing we'd probably like to start out with is mapping a container to the GPU, and evaluating a simple binary function, such as A + B.

[ktnyt]

Thanks for the prompt reply!

I haven't been able to make a deep dive into the code yet, but I was thinking that the implementation strategy from a recently released library called ChainerX might be of help. It basically provides device agnostic NumPy like multi-dimensional arrays for C++.
AFAIK they provide a Device abstract class that handles memory management and hides the hardware specific implementations for a core set of routines.
This is just an idea but the Device specialization for CPU specific code can be can be developed in parallel to xtensor and when it is mature enough switch out the portions of code calling the synonymous routines.
The GPU specialization can be filed in later and WIP routines can throw runtime or compile-time errors.

I'm not too familiar with the internals of xtensor so this might be an infeasible approach though.

[wolfv]

definitely a good idea to look at chainerx! Am Do., 24. Jan. 2019 um 17:25 Uhr schrieb ktnyt <notifications@github.com>:

…

Thanks for the prompt reply! I haven't been able to make a deep dive into the code yet, but I was thinking that the implementation strategy from a recently released library called ChainerX <https://github.com/chainer/chainer/tree/master/chainerx_cc> might be of help. It basically provides device agnostic NumPy like multi-dimensional arrays for C++. AFAIK they provide a Device abstract class that handles memory management and hides the hardware specific implementations for a core set of routines. This is just an idea but the Device specialization for CPU specific code can be can be developed in parallel to xtensor and when it is mature enough switch out the portions of code calling the synonymous routines. The GPU specialization can be filed in later and WIP routines can throw runtime or compile-time errors. I'm not too familiar with the internals of xtensor so this might be an infeasible approach though. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2BPsBBpcRVFf9SXBkK3Lm5AVGmwLoRks5vGW3qgaJpZM4MiR_Y> .