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

Rewrite Stack to be double stack #2138

Merged
merged 4 commits into from Oct 26, 2017
Merged

Conversation

tsholmes
Copy link
Member

Stack operations had to shift everything in the above stack up and down on every push and pop. The above stack is usually small since it is just the context chain, but the extra shuffling adds up. This switches it to be two separate stacks (implemented as fixed-size arrays to avoid re-allocating), changing the MoveStackPointer into PushAbove and PopAbove, as it was never used for transferring between the stacks, just for accessing the above stack.

This reduces the runtime of my sort script from ~16 seconds to ~14.5 seconds.

Copy link
Member

@Dunbaratu Dunbaratu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few suggestions from my reading tonight. I'm not done, but I need to quit for the night. If you want to react to these and make further edits, feel free.

private int stackPointer = -1;
private readonly object[] stack = new object[MAX_STACK_SIZE];
private int count = 0;
private readonly object[] aboveStack = new object[MAX_STACK_SIZE];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should stop calling this "above".
If we're changing this into two different stacks, I think it we should also change the terminology.
This was called the "above" stack purely because of where it was located - above the other stack.
This terminology change should also affect all the other places the word "above" is used to refer to this stack, like PopAbove, PushAbove, aboveCount, etc. There may also be mentions of this in comments trying to explain the "above stack", which should change too.

Ideas for new term: scopeStack, or callStack.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self: this will be a source of merge conflict for me: On the subject of creating the stack so it stays permanently at MAX_STACK_SIZE all the time - I had a change in my clock cycle branch designed to do this already but it wasn't ready to post it - I was keeping it as a stack (not an array) but telling .net to pre-allocate the stack to the full capacity. I will need to take care when updating that branch to develop because this will conflict for sure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yeah good point. i was just trying to keep things as similar as possible, but some clearer naming here would definitely make this more approachable in the future.

// inside it will always be backwardly printed):
for (int index = stack.Count - 1; index >= 0; --index)
// To simulate a single stack with the SP in the middle, we go through the aboveStack bottom up, then
// the normal stack top down
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're changing the underlying implementation, I don't mind exposing that fact to users in the Dump() output. This is meant to be a dump of what is really going on under the hood, so we should just print out the two stacks as two different stacks, labeled accordingly.

@@ -203,6 +238,28 @@ public string Dump()
}
}

private void dumpItem(int index, bool isSP, object item, StringBuilder builder)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like moving this out - it was getting nested a bit too deep.

@Dunbaratu
Copy link
Member

Dunbaratu commented Oct 26, 2017

A checklist of things I'm going to edit in my review - just to make sure I get all of them:

  • We should have two different MAX_STACK_SIZE values now, one for each stack, just in case we feel like setting their limits differently from each other later.
  • Instead of peeking a negative number to get to the scope stack, explicitly provide separate scope stack peeking API that uses positive numbers, and throw a "you should never see this" exception if we still pass in a negative number somewhere. This change also has to propagate upward through the CPU and ICPU wrappers around the stack methods providing separate methods there too.
  • Instead of "scope stack" and "stack", rename the "stack" to "argument stack" so both stacks have descriptive names. This includes:
    • Rename them inside Stack.cs and IStack.cs, and renaming all the API methods accordingly.
    • Rename their wrapper methods inside CPU.cs and ICPU.cs to give the same effect.
  • Some comments still refer to the way the "above stack" worked. They are easy to miss because they're comments so don't affect compilation. Edit comments to explain things the new way.

@Dunbaratu Dunbaratu merged commit 1d6f952 into KSP-KOS:develop Oct 26, 2017
@Dunbaratu Dunbaratu added this to the v1.1.4.0 milestone Dec 23, 2017
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.

None yet

2 participants