-
Notifications
You must be signed in to change notification settings - Fork 708
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
Remove intrusive_list (NFC) #2299
base: main
Are you sure you want to change the base?
Conversation
ebc4b36
to
deb0a58
Compare
// * No initializer lists | ||
// * Asserts instead of exceptions | ||
// * Some functions are not implemented (merge, remove, remove_if, reverse, | ||
// unique, sort, non-member comparison operators) |
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.
Do you know the rationale for creating this class in the first place? Does the reasoning for it no longer hold?
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.
It's not super clear (#542), but generally the reason to prefer an intrusive list vs. std::list
is about performance (an intrusive_list only needs one allocation to make a list node with both the contained object and the prev/next pointers). And indeed, I just benchmarked this PR (with wasm-validate
clang.wasm) and std::list
is a significant slowdown for large modules. :-(
main branch:
time ./bin/wasm-validate ~/w2c2/examples/clang/clang.wasm
real 0m1.887s
user 0m1.451s
sys 0m0.436s
this PR:
time ./bin/wasm-validate ~/w2c2/examples/clang/clang.wasm
real 0m2.967s
user 0m2.531s
sys 0m0.436s
I wasn't expecting it to be this bad -- let's hold off on this for now until I find a better way.
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 believe I originally switched from a vector to an intrusive list, since I thought we'd want to be able to do insertions into the list. I'm not sure that was a good decision, tbh. It may make sense to see whether switching it back to a vector would work.
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.
Well, here's a version with std::vector for the ExprList and std::deque for the ModuleFieldList (since we sometimes iterate over the ModuleFieldList while also appending to it...). Still unfortunately a performance regression, but not as bad as before:
$ time ./bin/wasm-validate ~/w2c2/examples/clang/clang.wasm
real 0m2.456s
user 0m1.972s
sys 0m0.484s
deb0a58
to
0eec053
Compare
Reverting to draft -- I think changing ModuleFieldList away from intrusive_list in a way that doesn't introduce a performance regression will take a more involved change. The Module structure has internal pointers pointing inside the ModuleFieldList, and likes to iterate over the ModuleFieldList while appending to it, so a naive replacement with vector isn't safe (and even deque fails -- in the fuzzer only, not in any of the asan spec tests, which spooks me a bit). |
0eec053
to
435af28
Compare
This PR replaces the
intrusive_list
class with a std::list of unique_ptr's, trying to keep everything else mostly the same.