-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat(map): Allow chaining lists before mapping #136
Conversation
a292324
to
91f80d8
Compare
Looks very good. Two observations:
|
True. I guess that pertains mainly to
Potentially yes. The one thing I tried was accessing |
91f80d8
to
67d1292
Compare
Please note that I rebased this branch against |
Apart from your suggestions, I also made one more addition that might be worth reviewing: the type
Let me know if you have any suggestions to improve this design. |
Is the change to the initial state generator a likely explanation? If so, are we fine with the benchmark changing more dramatically than the changes to the assembly alone would suggest? |
Yes, we are fine with that. But with the suggested change of using the Other benchmarks reveal the performance changes to |
assert_eq!(1, sn.input_types().len(), "{INNER_FN_INCORRECT_NUM_INPUTS}"); | ||
let fn_body = sn.function_code(library); | ||
let (_, instructions) = tokenize(&fn_body).unwrap(); | ||
let labelled_instructions = isa::parser::to_labelled_instructions(&instructions); | ||
let snippet_name = | ||
library.explicit_import(&sn.entrypoint_name(), &labelled_instructions); | ||
(triton_asm!(call { snippet_name }), String::default()) | ||
let label = library.explicit_import(&sn.entrypoint_name(), &labelled_instructions); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some reason, we are using explicit_import
here. I'm not 100 % sure that's necessary. Maybe we can just use the import
method directly on the snippet instead? Or maybe there's some borrowing check that fails if you do that? Unsure. Feel free to investigate, or to just ignore this comment, as the current approach works just fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried that, but could not get it to work. The main culprit seems to be the trait object snippet
, which is of type &Box<dyn BasicSnippet>
. Library::import()
requires a Box<dyn BasicSnippet>
. Dereferencing snippet
does not work because that would constitute a move, but the method only takes &self
. Similar problems arise when changing the match statement to match self.f
instead of &self.f
. Cloning the snippet
also does not work, because the Snippet
trait does not have a trait bound on Clone
. When trying to introduce such a trait bound, all hell breaks lose.
Long story short: it might be possible, but I decided to give up after a few minutes of trying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, my comment is about the match arm one further down. The place where you put the comment has the additional complication that the type of sn
is &Box<dyn DeprecatedSnippet>
, which would have to be transformed into a Box<dyn BasicSnippet>
first.
cd5ef3d
to
f25b154
Compare
Previously, the higher-order assembly function `map` took all elements of an input list, mapped them according to some supplied function, and generated an output list. Equivalently, written in rust, this was:`list.into_iter().map(f).collect_vec()`. Now, `map` is generalized over the number of input lists, enabling chaining multiple input lists while still producing only one output list. As rust: `list_0.into_iter().chain(list_1).map(f).collect_vec()`. Between 0 and 15 (both inclusive) input lists are supported. Note: the ABI for map has changed. Before, an inner function could access runtime parameters on the stack at a distance of 3. Now, this distance has increased to (3 + num_input_lists). For a “traditional” map, this is now 4.
f25b154
to
031927a
Compare
Previously, the higher-order assembly function
map
took all elements of an input list, mapped them according to some supplied function, and generated an output list. Equivalently, written in rust, this was:list.into_iter().map(f).collect_vec()
.Now,
map
is generalized over the number of input lists, enabling chaining multiple input lists while still producing only one output list. As rust:list_0.into_iter().chain(list_1).map(f).collect_vec()
.Between 0 and 15 (both inclusive) input lists are supported.
Note: the ABI for map has changed. Before, an inner function could access runtime parameters on the stack at a distance of 3. Now, this distance has increased to (3 + num_input_lists). For a “traditional” map, this is now 4.