I did not include any multi-threading in rlic yet because I wanted to set a solid baseline for single-core performance first, and because I was assuming that any need for parallelism could be addressed on the user side in Python, but experiments conducted in brylic seem to indicate that there is a non-neglible gain to be had when handling parallelism in rust, so I would like to study it more closely.
Meanwhile, I think I should be able to prototype an interface for it in Python, which will also help with checking results from brylic.
I'm thinking the interface could be reduced to exposing a max_tile_size argument in rlic.convolve
which would always be internally converted to a tuple[int, int], but would accept a single int, n as equivalent to (n, n), would special case -1 to mean "match the image size" and would be (-1, -1) by default.
It's important that we only expose the maximum tile size because there are at least 2 reasons why tiles could still end up smaller than requested:
- the whole image itself is smaller (no reason to crash)
- avoid repeated work if for instance the image as a size of (n, n) and
max_tile_size=(n-1, n-1)
To avoid loss of data, tiles need to overlap, but the size of the overlaps doesn't need to be larger than the kernel size.
To the extent that's possible, internal machinery should determine the actual tile size in a way that maximize load balancing.
I did not include any multi-threading in
rlicyet because I wanted to set a solid baseline for single-core performance first, and because I was assuming that any need for parallelism could be addressed on the user side in Python, but experiments conducted inbrylicseem to indicate that there is a non-neglible gain to be had when handling parallelism in rust, so I would like to study it more closely.Meanwhile, I think I should be able to prototype an interface for it in Python, which will also help with checking results from brylic.
I'm thinking the interface could be reduced to exposing a
max_tile_sizeargument inrlic.convolvewhich would always be internally converted to a
tuple[int, int], but would accept a single int, n as equivalent to(n, n), would special case-1to mean "match the image size" and would be(-1, -1)by default.It's important that we only expose the maximum tile size because there are at least 2 reasons why tiles could still end up smaller than requested:
max_tile_size=(n-1, n-1)To avoid loss of data, tiles need to overlap, but the size of the overlaps doesn't need to be larger than the kernel size.
To the extent that's possible, internal machinery should determine the actual tile size in a way that maximize load balancing.