As the title says, the imaging (and spectral data cube) calculation can now be distributed over threads.
The wins are less big here since cache clashes are all but guaranteed when assigning into the image/data cube. This could be alleviated by allocating an image per thread but that could quickly lead to huge memory footprints. That said there's still an improvement.
I created a worst-case scenario concentrated galaxy (which will guarantee the same pixels are assigned to repeatedly) and got the following scaling for imaging:
and spectral data cubes:
These are far off the perfect scaling but there is still a win. A real situation will perform better due to the less uniform layout of particles.
Issue Type
Enhancement
Checklist
[x] I have read the [CONTRIBUTING.md]() -->
[x] I have added docstrings to all methods
[x] I have added sufficient comments to all lines
[x] I have made corresponding changes to the documentation
[x] My changes generate no pep8 errors
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
As the title says, the imaging (and spectral data cube) calculation can now be distributed over threads.
The wins are less big here since cache clashes are all but guaranteed when assigning into the image/data cube. This could be alleviated by allocating an image per thread but that could quickly lead to huge memory footprints. That said there's still an improvement.
I created a worst-case scenario concentrated galaxy (which will guarantee the same pixels are assigned to repeatedly) and got the following scaling for imaging:
and spectral data cubes:
These are far off the perfect scaling but there is still a win. A real situation will perform better due to the less uniform layout of particles.
Issue Type
Checklist