Skip to content

Add CPU estimation of largest reslice in pipeline#731

Open
yousefmoazzam wants to merge 2 commits into
mainfrom
peak-reslice-estimator
Open

Add CPU estimation of largest reslice in pipeline#731
yousefmoazzam wants to merge 2 commits into
mainfrom
peak-reslice-estimator

Conversation

@yousefmoazzam

Copy link
Copy Markdown
Collaborator

Fixes IMGDA-907

The idea behind this was to reuse the existing CPU memory estimation of the full pipeline, and assume that the peak value would be contributed by the peak reslice, wherever that occurred in the pipeline.

The reuse of the existing CPU memory estimation function estimate_section_memory() meant that it was possible to reuse all the existing functionality that loops over sections and calculates the output chunk shape of each section, which would be needed for a "peak reslice estimator".

Checklist

  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I have made corresponding changes to the documentation
  • I have added the user-release-note label in order to include this PR in the "Notable
    Changes for Users" section in release notes

…mation

When performing CPU memory estimation of a section at runtime, any
change to the data shape during the processing is naturally propagated
due to the output of a section being passed as the input of the next
section, so the data source's shape could be inspected to know if the
data shape had changed.

When performing CPU memory estimation of the entire pipeline prior to
httomo runtime, there's no processed data to pass along, and thus the
transformation of the data shape must be accounted for in some other
way.

This change passes along the estimated output chunk shape of a section
to the input of the next section, to then achieve this propagation of
data shape transformation. Note that it assumes that the global shape of
the data will be the size of a chunk multiplied by the number of
processes, which is roughly correct but may very slightly overestimate
in some cases; this is due to the fact that, depending on the input data
shape, the splitting of data across multiple processes could result in
one or more of the processes getting slightly less data as a consequence
of the data shape not being evenly divisible along the slicing
dimension.
@yousefmoazzam yousefmoazzam force-pushed the peak-reslice-estimator branch from 6c5835a to 7052305 Compare June 18, 2026 14:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant