Use flow decomposition code from David Aulicino as a benchmark #169
Conversation
David Aulicino shared a Jupyter notebook with us that (in June 2021) took about 12h to complete. This adds a simplified version of that notebook that contains the bits that take 99% of the runtime. The computationally difficult part is computing all the flow decompositions for directions coming from saddle connections up to some length. (In the original notebook that length was given as 400 for the square of the actual length.)
|
We're now down to 20s for this computation. (But I am starting to doubt that the original computation went only to sqrt(400) and not to 400…then again, I am pretty sure that that's what we had back then and it's also what David wrote in his message.) |
|
Parallelizing and doing this over a number field, I'm down to 2s + SageMath startup. |
|
Using a Delaunay triangulation, 1s. But I am now probably at the point where I am measuring how quickly my CPU ramps up to boost frequency. |
|
If there's symmetries in this surface (didn't check,) then we could use #35 to further speed this up. |
|
Apart from the SageMath startup, the time is spent in the saddle connection search, flipping edges to get a unique large edge, and not much time in the flow decomposition algorithm. That's not too surprising and what I expect from my last round of speeding up orbit closure computations. A lot of time is spent inside these steps multplying exact real numbers (I marked some in green.) That's what disappears when using a number field instead. |
|
Documentation preview for this PR is ready! 🎉 |
David Aulicino shared a Jupyter notebook with us that (in June 2021)
took about 12h to complete. This adds a simplified version of that
notebook that contains the bits that take 99% of the runtime.
The computationally difficult part is computing all the flow
decompositions for directions coming from saddle connections up to some
length.
(In the original notebook that length was given as 400 for the square of
the actual length.)