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

Add a MergeDeferredDataSource which combines multiple data sources #35

Merged
merged 8 commits into from
Oct 21, 2023

Conversation

elliottslaughter
Copy link
Contributor

@elliottslaughter elliottslaughter commented Oct 20, 2023

This PR adds a new MergeDeferredDataSource that combines multiple data sources into a single logical data source. There are a couple of use cases this addresses:

  1. Very large profiles may not fit in the memory of any one machine. Now you can slice those profiles into pieces, --serve them on different nodes, and --attach them all, stitching them back into a single logical profile.
  2. When running Legion as a per-rank runtime within MPI, Legion produces N distinct profiles. Then you can use this mode to stitch them back together.

There's an accompanying backend change that goes along with this that I'm still working on. This change introduces the basic MergeDeferredDataSource as a building block that those changes can sit on top of.

Known limitations:

  • The tile sets need to be identical across all the data sources. That means currently there's no meaningful way to use it with --archive mode in the backend (i.e., you must use a live server). This could be supported, but it would be costly and I'm not honestly sure it's worth it. Alternatively we could handle this better in the backend.

tile_set,
field_schema,
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on basic unit tests for functions like this? They seem amenable to unit testing but maybe relying on the compiler for assurances is more common in Rust-land?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look at the most recent push and see if it seems reasonable.

In general, Rust users do rely a lot on the type system to make sure things work. And Rust's type system is pretty good, so I have a lot of confidence when things compile. But there are still classes of logic errors we hit, so it would be better to add more unit testing in general. So thanks for the reminder.

Copy link
Contributor

@bryevdv bryevdv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM just one minor suggestion to consider

Comment on lines 426 to 452
let EntryInfo::Slot {
short_name: slot0_short_name,
..
} = &slots[0]
else {
panic!("unexpected variant result in slot 0");
};

let EntryInfo::Slot {
short_name: slot1_short_name,
..
} = &slots[1]
else {
panic!("unexpected variant result in slot 1");
};

let EntryInfo::Slot {
short_name: slot2_short_name,
..
} = &slots[2]
else {
panic!("unexpected variant result in slot 1");
};

assert_eq!(slot0_short_name, "S1");
assert_eq!(slot1_short_name, "S2");
assert_eq!(slot2_short_name, "S3");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only suggestion would be to keep related cases entirely together rather than group by "operation"

Suggested change
let EntryInfo::Slot {
short_name: slot0_short_name,
..
} = &slots[0]
else {
panic!("unexpected variant result in slot 0");
};
let EntryInfo::Slot {
short_name: slot1_short_name,
..
} = &slots[1]
else {
panic!("unexpected variant result in slot 1");
};
let EntryInfo::Slot {
short_name: slot2_short_name,
..
} = &slots[2]
else {
panic!("unexpected variant result in slot 1");
};
assert_eq!(slot0_short_name, "S1");
assert_eq!(slot1_short_name, "S2");
assert_eq!(slot2_short_name, "S3");
let EntryInfo::Slot {
short_name: slot0_short_name,
..
} = &slots[0]
else {
panic!("unexpected variant result in slot 0");
};
assert_eq!(slot0_short_name, "S1");
let EntryInfo::Slot {
short_name: slot1_short_name,
..
} = &slots[1]
else {
panic!("unexpected variant result in slot 1");
};
assert_eq!(slot1_short_name, "S2");
let EntryInfo::Slot {
short_name: slot2_short_name,
..
} = &slots[2]
else {
panic!("unexpected variant result in slot 1");
};
assert_eq!(slot2_short_name, "S3");

Copy link
Contributor

@bryevdv bryevdv Oct 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh and that last case should read "unexpected variant result in slot 2" (up above as well)

@elliottslaughter elliottslaughter merged commit 3dd6ef7 into master Oct 21, 2023
12 checks passed
@elliottslaughter elliottslaughter deleted the merge-data-source branch October 21, 2023 00:10
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.

2 participants