Repository navigation
Switching to the C stack is slow #1801
Description
Activity
Branch prediction is the reason the stack-growth
__morestackfunction has such a bizarre structure.Possibly we can just use the stack-growth
__morestackfunction to do stack switching as well by setting the stack boundary to a value that is guaranteed to trip the call to__morestackand setting a flag in the task structure to put it into a different 'mode'. This would make branch prediction work and eliminate the need to marshall arguments through a struct on the stack.We tried using __morestack for this and it had too much overhead from other stack growth code to make it worthwhile.
Visiting for triage; still relevant.
Triage: #8535 changed (some of) the way
extern fns work, so I have no idea if this is valid, and I can't create a testcase that reproduces it (possibly because segmented stacks are disabled in the new rt?).@nikomatsakis would your changes have affected this?
@huonw yes and no. We no longer use the old C stack switching mechanism, we only use the "stack-growth" variant of
__morestack. Moreover, users can now move the stack switch so it occurs earlier, which helps to eliminate overhead. However, the mechanism itself is still probably too slow -- though whether it can be further optimized is unclear, @pcwalton thought no. Certainly we can't eliminate the megamorphic call site that Brian referred to.Obsolete
- added a commit that references this issue
on Jun 4, 2024
pcwalton saw the C-stack-switching
__morestackfunction show up surprisingly high on profiles. All this function does is change sp and call a function by pointer. Probably this is very bad for branch prediction.