Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduction-related code and explanation in the circuit example is out-dated #12

Open
Anjiang-Wei opened this issue Jan 5, 2023 · 4 comments

Comments

@Anjiang-Wei
Copy link
Contributor

The tutorial mentions several times the code related with the AccumulateCharge class, but the explanation does not seem to match the latest implementation of circuit example.
I believe that the reduction operator has been integrated into Legion itself, e.g., the current version simply needs to use LEGION_REDOP_SUM_FLOAT32

I wish I could make a PR for this to improve the circuit tutorial to better match the current code of the circuit example and the overall Legion design, but currently, I have very little experience in using the reduction operator, so I decided to open an issue here for now.

@Anjiang-Wei
Copy link
Contributor Author

I do not quite get the intuition of differences between reduction list and reduction fold. More specifically, the reason why people want to differentiate the two notions.

@Anjiang-Wei
Copy link
Contributor Author

Also, I am curious whether scan is a "parallel primitive" that Legion supports or will support.

@Anjiang-Wei
Copy link
Contributor Author

Anjiang-Wei commented Jan 8, 2023

I do not quite get the intuition of differences between reduction list and reduction fold. More specifically, the reason why people want to differentiate the two notions.

I think I understand it better by reading the tutorial twice. Reduction list corresponds to reduction without fold. Also, intuitively I can understand that reduction+fold has the potential to enable more optimization than reduction itself. Is there a simple but real-world example where we can only use reduction without a fold? It would be great if we could make the tutorial easier to follow for beginners like me.

Also, I feel a bit confused about the following statements in the tutorial:

Reduction list instances perform best when reductions are sparse in the target logical region and the resulting list of reductions has fewer elements than the target logical region. Alternatively, fold reduction instances perform best for dense reductions where more than one reduction operation will be applied to each location in the logical region. Locally folding reductions saves space and allows reductions to be performed in parallel.

More specifically, what does more than one reduction operation mean? Does it correspond to the code where reduce_node is invoked twice inside the function cpu_base_impl?

@lightsighter
Copy link
Contributor

I do not quite get the intuition of differences between reduction list and reduction fold. More specifically, the reason why people want to differentiate the two notions.

Section 7.1 of this paper covers the distinction. I will say the reduction list implementation is not really supported right now. I would need to resurrect it to bring it back so probably worth removing it from the manual if it is in there currently.

Reduction list corresponds to reduction without fold.

It does have that benefit as well, although the original motivation is the one above. Right now I think we assume that a fold function always exists on our reduction operators currently.

More specifically, what does more than one reduction operation mean? Does it correspond to the code where reduce_node is invoked twice inside the function cpu_base_impl?

See if the paper above answers you question. If not, let me know and I'll take a crack at answering it differently.

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

No branches or pull requests

2 participants