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

Framestepping, improve performance on large steps #26

Closed
SimonN opened this Issue Jan 13, 2016 · 2 comments

Comments

Projects
None yet
1 participant
@SimonN
Owner

SimonN commented Jan 13, 2016

Version: 0.1.29

How to repro: Framestep backwards. The game will use the close-by saved states to recalculate. At some time, there will not be a nice close-by state. The game will load an old state, recalculate, and save finer-grained, more close-by, states, along the way. This takes some time, and produces a visible pause on my 9-year-old laptop.

Problem: Many of these states will be tossed right during the very same long recalculation. If we save every 10 frames a state that, with hope, is close-by, we don't have to save this 25 times when recalculating from the 250-frame-old step. Only the last two 10-frame-old states will end up in the state mangager.

Possible solution: In the updating logic, keep info about what state ultimately to end up at. Pass that to the savestate manager along with the current update proposal.

Framestepping is important! ❗️ Bad performance is a bug! 💤 Mediocre performance is a subtle bug! 🐌 We want the cutting edge in backwards interactive rodent simulation! ⚡️⚡️⚡️

@SimonN SimonN added the 4-minor label Jan 13, 2016

@SimonN SimonN closed this in 930a306 Jan 13, 2016

@SimonN

This comment has been minimized.

Show comment
Hide comment
@SimonN

SimonN Jan 13, 2016

Owner

Implemented the possible solution from the OP as-is. Over 100 % speed increase on longer framestepping computations (recalculations from a rather old savestate). No noticeable slowdown for short compatations. The number of saves generated seems to be optimal in theory for this model (several pairs of states, the two states in a pair leapfrog each other).

Any type of debugging or profiling slows down longer computations noticeably, which is expected, because these computations are the most expensive in the entire program.

Owner

SimonN commented Jan 13, 2016

Implemented the possible solution from the OP as-is. Over 100 % speed increase on longer framestepping computations (recalculations from a rather old savestate). No noticeable slowdown for short compatations. The number of saves generated seems to be optimal in theory for this model (several pairs of states, the two states in a pair leapfrog each other).

Any type of debugging or profiling slows down longer computations noticeably, which is expected, because these computations are the most expensive in the entire program.

@SimonN

This comment has been minimized.

Show comment
Hide comment
@SimonN

SimonN Jan 14, 2016

Owner

In D, classes are reference types and structs are value types. Savestates consist of many, many of the following:

class Lixxie { ... } // each instance has one of
class PerformedActivity { ... } // with many polymorphic subclasses

This can be expensive to copy. Making or loading a savestate may mean that about 100 to 2000 objects will be new'd on the garbage-collected heap. It's a bit tricky to convert both to value types, and placement-new doesn't bode well with polymorphism as-is.

Would love to do savestating by memmoving a few large chunks instead of new'ing 2000 objects.

Owner

SimonN commented Jan 14, 2016

In D, classes are reference types and structs are value types. Savestates consist of many, many of the following:

class Lixxie { ... } // each instance has one of
class PerformedActivity { ... } // with many polymorphic subclasses

This can be expensive to copy. Making or loading a savestate may mean that about 100 to 2000 objects will be new'd on the garbage-collected heap. It's a bit tricky to convert both to value types, and placement-new doesn't bode well with polymorphism as-is.

Would love to do savestating by memmoving a few large chunks instead of new'ing 2000 objects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment