| Commit-Queue | +1 |
Christmas came early this year and I have this huge refactoring CL for you :'D
I've been meaning to do this for >1 year now and finally got around to it (with some help from gemini :)). We use the same tagging mechanism now for all major pointer tables (external, cppheap, trusted). The generic implementation of untagging is slightly more expensive, and there seem to be a few small regression from this CL. However, I think we'll be able to recover them in follow-ups by using "fast" tags (see commit description and next CL in the chain). Basically, with that the previous tagging mechanism becomes the fast case for the new, more generic one. I'd appreciate if you had thoughts about which trusted objects might be particularly performance sensitive, and so should be converted to fast tags to try and recover the regressions.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
📍 Job mac-m1_mini_2020-perf/speedometer3 complete.
See results at: https://pinpoint-dot-chromeperf.appspot.com/job/13e2c9b0b10000
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This is slightly slower on all pinpoints? :/
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This is slightly slower on all pinpoints? :/
As mentioned in the other comments and discussed offline, the CL is expected to cause some small regressions as the generic untagging mechanism now needs a few more instructions. The follow-up CL introduces "fast tags" which then again only require a single AND instruction to untag. The plan would be to identify which tags need to be fast (e.g. by landing this CL and seeing which benchmarks regress), then converting those to fast tags to recover the regressions.
But let's come back to this in January after the holiday break :)
constexpr IndirectPointerTagRange kAllSharedIndirectPointerTags(Maybe kAnyXyz ?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Samuel GroßThis is slightly slower on all pinpoints? :/
As mentioned in the other comments and discussed offline, the CL is expected to cause some small regressions as the generic untagging mechanism now needs a few more instructions. The follow-up CL introduces "fast tags" which then again only require a single AND instruction to untag. The plan would be to identify which tags need to be fast (e.g. by landing this CL and seeing which benchmarks regress), then converting those to fast tags to recover the regressions.
But let's come back to this in January after the holiday break :)
So it looks like with https://chromium-review.googlesource.com/c/v8/v8/+/7246171 we fully recover the regressions (and the Speedometer3 on Linux even shows improvements, though not sure where they would come from).
Let's get back to this CL now that the holiday break is over :) I've updated the follow-up CL and it seems to now fully recover the regression introduced by this CL. PTAL!
constexpr IndirectPointerTagRange kAllSharedIndirectPointerTags(Maybe kAnyXyz ?
Let me know if anyone has preferences regarding the name of these ranges (kAllXyz vs kAnyXyz)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |