Repository navigation
Faster AppendedTrajectoryEnsembles - #231
Conversation
Still need to do the same for can_prepend.
dwhswenson
changed the title
Timing test
|
As mentioned in #222, the prepend cost is actually only "near-linear." The nonlinearity is visible (see I've done what I can to speed things up here. Hypothetically, a different implementation of the sequential ensemble could speed it up a bit (by replacing the current approach with an approach which assigns frames to the trajectories, and then uses that assignment as a cache). I've attached a recent call graph (from a 200-cycle RETIS calculation). You'll have to load it to read anything, of course, but a few main points:
Part of the problem with Anyway, this is ready to merge now. I'm getting reasonably faster (and much more consistent) calculation speeds.
|
dwhswenson
changed the title
Now all test trajs in testensemble are passed through make_1d_traj. Before, we added this on the trajs for BackwardPrepended tests. Advanced in openpathsampling#242 make that redundant.
|
Application of other PRs made this unmergeable, and #242 made a step in the tests here redundant (and thus they would throw errors). All of that should now be fixed, and (assuming it passes tests, which it should) this should be ready for review and merge. |
|
Fixed so that this is ready to be merged again (at least, if we merge it before merging anything else this time!) |
|
lets go... |
Faster AppendedTrajectoryEnsembles
2 participants
Once this is done, trajectory generation should be blazing fast.
ForwardAppendedTrajectoryEnsembleForwardAppendedTrajectoryEnsembleBackwardPrependedTrajectoryEnsembleBackwardPrependedTrajectoryEnsembleI'm also overriding the unused of
can_append/can_prependfor these to raise an error if called.ForwardAppendedTrajectoryEnsemble.can_prependis nonsense: I'm not even sure what the expected behavior would be, so I'm calling it an error.Fixes #222.