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

Intern, as DataInstForm, the kind and output_type fields of DataInstDef. #28

Merged
merged 1 commit into from
Jun 7, 2023

Conversation

eddyb
Copy link
Contributor

@eddyb eddyb commented May 1, 2023

This should, in theory, allow reusing one DataInst "form" (or "template") for many DataInsts, with only runtime inputs (and/or attributes) differing between their "instances".

While there is no good reason to have the extra indirection today (and the performance impact seems to fall within noise), there is a refactor I want to try (which would require multiple outputs per DataInst, and that would add to the growing size of DataInstDef, before this interning change).

Will keep this PR as draft until I can confirm that refactor is successful.

@eddyb eddyb marked this pull request as ready for review June 7, 2023 05:59
@eddyb
Copy link
Contributor Author

eddyb commented Jun 7, 2023

Will merge before #29 is ready, as that's quite literally an order of magnitude bigger already, and there's no reason to further complicate rebases by delaying this any longer.

@eddyb eddyb merged commit c32ae33 into main Jun 7, 2023
@eddyb eddyb deleted the forms branch June 7, 2023 06:05
github-merge-queue bot pushed a commit to Rust-GPU/spirt that referenced this pull request Nov 6, 2024
…`). (#12)

Effectively undoes:
- EmbarkStudios/spirt#28

Some quick unscientific testing reveals no significant perf impact (i.e.
the difference is lost in the noise).

The motivation for undoing this interning is the prospect of combining
`DataInstDef` into `NodeDef` (as mentioned in #7), and for unrelated
pragmatic reasons, `NodeDef` can't have its outputs interned (though
long-term maybe we could intern the `kind` field, if really necessary,
assuming we first take "child regions" out of it).

The one thing I realized too late there's no pre-existing consensus for,
is the `output_type`, which used to be between `kind` and `inputs`
(matching `DataInstFormDef`, in fact), while `NodeDef`'s `outputs` is
the last field.

The only argument to have outputs first is the `let (out0, out1) =
foo(in0, in1);` style syntax (though pretty-printed SPIR-T omits the
`let`), but I'm not sure that's worth flipping the order over.
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