The Need for Speed

[KelSolaar]

Hi,

Starting a new issue to discuss about performance improvements and mainly to trackdown the things I have been following since a while.

GPU Backend

Ideally, we want Numpy to work on the GPU for free, unfortunately, this is not the case, good candidates that came up in recent years:

• CuPy: I started to filter which Numpy definition we were using and were supported or unsupported by CuPy in the following spreadsheet: https://docs.google.com/spreadsheets/d/1DoHq1n2CcdC0yYK3xW0qZ6_X6yZkJHjamwYAK8W0KVo/edit?usp=sharing
• https://github.com/bh107/bohrium: Looks promising, I haven't tried recently but it was breaking for me back then.

Cython and Rust

Cython is not super exciting and I would tend to lean toward Rust because the future is bright for it and @MichaelMauderer has done some conclusive tests. @anderslanglands has a library here too: https://github.com/anderslanglands/colorspace-rs

[MichaelMauderer]

+1 for Rust.
A while back compared numpy and Rust for an array-based CIELAB conversion and Rust came out on top.

But if GPU support is of interest, it might be good to also look at OpenCL.

[KelSolaar]

The enticing aspect with the GPU, and especially with projects such as Bohrium or Cupy is that ideally, you really just have to do import Bohrium as np or import Cupy as np, in practice and on a complex project like Colour it is 100% certain that it will break somewhere :)

As for Rust, we discussed about a new repo, e.g. colour-rs or alike (I was even thinking about joining forces with Anders), where we could start to replicate Colour functions and, optionally, trying to make them available to Colour itself. This path is more elegant than Cython because colour-rs would essentially be standalone but could be leveraged by Colour if needed.

[MichaelMauderer]

Agree, if the GPU support is a drop-in replacement that would be awesome, but it's unlikely to be that easy. But then it may still be less work than a re-implementation of colour in another language.

PyOpenCL seems to be similar to PyCuda. I think the alure of such a solution is, that it could be direcly integrated into rendering pipelines. Using frames already on thre GPU and the data never has to leave GPU memory.

One advantage of colour-rs would be that it could be leveraged as the basis for bindings in a lot of languages. Python, JS, C/C++. But it would be a CPU based solution.

[MichaelMauderer]

I take back the statement that PyOpenCL is similar to PyCuda. PyCuda seems to have far more integration into numpy.

[KelSolaar]

But then it may still be less work than a re-implementation of colour in another language.

Both paths are not mutually exclusives and I quite like both, that being said having GPU support would probably be more important I reckon.

[MichaelMauderer]

Do you have specific performance metrics or application profiles in mind?

[KelSolaar]

I have a few processing pipelines related to Colour - HDRI where I would need much better speed. That definition is for example super slow with 5-6K images: https://github.com/colour-science/colour-hdri/blob/develop/colour_hdri/recovery/highlights.py#L88

[anderslanglands]

I’d love to collaborate on a rust port (colorspace-rs is sort of that but more focused to a certain use case), but it seems like GPU would give you the biggest bang for your buck. Bohrium in particular looks very interesting from that point of view - managing transfers and kernel evaluations lazily for you.

…

On Sat, 19 Oct 2019 at 13:10, Thomas Mansencal ***@***.***> wrote: I have a few processing pipelines related to Colour - HDRI <https://github.com/colour-science/colour-hdri/> where I would need much better speed. That definition is for example super slow with 5-6K images: https://github.com/colour-science/colour-hdri/blob/develop/colour_hdri/recovery/highlights.py#L88 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#522?email_source=notifications&email_token=AAOYQXJ7PZFHOTOJTJT3L7TQPJGBDA5CNFSM4JCMRZL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBWQZ7Y#issuecomment-544017663>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOYQXIJGZ5WLPT5IJIUW7DQPJGBDANCNFSM4JCMRZLQ> .

[MichaelMauderer]

Do we have stats on which functions are most used in projects that have colour as a dependency?

[KelSolaar]

@MichaelMauderer : I would bet that Lab to XYZ and everything around it are hotspots, they are for me :) Not sure for dependents.

Related to that question: We lost the list Github was building for us when removing the setup.py file for Poetry. I will ping Github as it should work with the requirements.txt file too: https://github.com/colour-science/colour/network/dependents

@anderslanglands : Yeah, GPU seems the most promising path and it is probably the first thing I will try, that being said, I'm also happy to think about Rust in parallel. I don't have too many free cycles these days but later this year or next year could be a good time.

[MichaelMauderer]

Just another thought to leave here: is it possible to leverage OpenCV for GPU operations?

[KelSolaar]

Probably some parts yeah, I don't think it is generic enough though! Worth a look for sure.