-
-
Notifications
You must be signed in to change notification settings - Fork 602
speed up cached_function and cached_method #8611
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
Comments
comment:1
Attachment: trac-8611-speed-up-cached-decorators.patch.gz BEFORE PATCH:
AFTER PATCH
|
comment:2
A few doctests don't pass, including one troubling one that seems to indicate that |
comment:4
Might it not be better for E.g. the following code works for methods with no arguments:
I tested this and it's only about 1.5 times slower than doing the caching "by hand", while your speeded-up version above is still about 40 times slower. David |
comment:5
I just noticed that the patch does not apply anymore. I am trying to work on cached_function and cached_method anyway, so, I hope that I can soon submit a new patch. |
Work Issues: Patch doesn't apply |
comment:6
Hi Jason, Note also that your patch would break the cache in the case of default/named arguments. Namely, when you have a function The patch that I am now preparing is quite thorough, attacking several spots that created overhead. It can now nearly compete with manual caching. I am currently adding more doctests and hope that I will be able to provide a patch later today. Best regards, Simon |
Changed author from Jason Grout to Jason Grout, Simon King |
comment:7
Replying to @loefflerd:
It was not the case that there was a single cache for all instances (the cache was in the instance for I just attached a new patch that goes far beyond Jason's approach. These examples show how the cached method performance is Using instance attributes Polynomial ideals have a cached method
This already yields a considerable speedup. However, pickling posed The solution is "creative" (I hope you don't find it crazy - at least
Here is an example:
We now pickle and unpickle the ideal. The cached method
But as soon as any other attribute is requested from the
Creating the cache key
Moreover, I made a shortpath in the method
The solution is to compute the cache key for an empty argument list Accessing the cache Originally, a method By my patch, the cache is always available as an attribute of
There is an additional benefit of this approach: If the instance has Documentation I extended the documentation - but I did not cover Of course, all doctests pass for me. I did not test whether the documentation Performance Last but not least, what the ticket is about: Performance! Here is the setting:
Without my patch
With my patch
Here is the effect of using a shortpath:
Without my patch:
With my patch:
|
Changed work issues from Patch doesn't apply to none |
Changed keywords from none to cached method |
comment:8
For the patchbot: Apply trac8611_cached_method_overhaul.patch |
comment:9
I forgot to provide a comparison against an explicitly coded cache:
Hence, the new version of cached methods can almost compete with an explicitly coded cache, but is of course much more comfortable for the programmer. |
comment:10
I forgot to mention another bug fix (that is also doctested). It is about the comparison of representations of symmetric groups:
The ticket description states that the improvements concern the critical path (i.e., the value is already caught). Here is one more comparison, that also shows what happens in the non-critical path. Setting:
Without my patch:
With my patch:
Hence, the patch improves all cases. |
This comment has been minimized.
This comment has been minimized.
comment:11
In the patch version that I've just attached, I also inserted the documentation of |
Improved performance for cached methods; add documentation to reference manual; cache is_subcateory. Replaces Jason's patch |
comment:13
Attachment: trac8611_cached_method_overhaul.patch.gz I slightly changed the patch. But the small change has in fact a big impact: The method I suggest that I believe that the additional memory consumption is affordable: When starting Sage, there are precisely 55 categories, so, in the worst case, caching The impact on the overall performance is obvious: Hence, the average improvement is about 4.5%. |
comment:14
Apply trac8611_cached_method_overhaul.patch (for the patchbot) |
comment:15
Replying to @loefflerd:
There already was such message for the patchbot. But one question: On sage-devel, Robert Bradshaw reported that I need to rebase the patch. But the patchbot - at least in one attempt - succeeded. So, what is the status? Unfortunately, I seriously screwed up my Sage installations. Currently, my two ol installations are broken, and sadly I was unablee to build either sage-4.6.1 or sage-4.6.2.alpha0/1. Cheers, Simon |
comment:16
Replying to @simon-king-jena:
Patchbot's a bit pedantic about formatting of such messages. If you look at the records of the test runs it's done, you'll see that prior to today it was trying to apply both patches at once, and thus failing, and after I prodded it earlier, it did a new run which passed. I've got a working 4.6.2.alpha0 build, so I can test it against that tomorrow morning. |
comment:17
Applies fine and passes doctests both using 4.6.2.alpha0 on my system, and using 4.6.1 with patchbot. I ran some tests and in the case of a method with no arguments it's something like 15 times faster than the old code and only a tiny bit slower than a hand-rolled cache. Code looks fine by eye, and it's great that you added these modules to the ref manual as well. Positive review. I'm looking forward to using %prun in future sage versions and not finding that 20% of the execution time has been spent in "fix_to_pos", which is frequently the case at the moment... |
Reviewer: David Loeffler |
comment:18
Please use line breaks in the commit message if it is so long. Make sure the first line is a short description of the patch with the ticket number. Following lines can contain a longer description. |
Apply only this patch |
comment:19
Attachment: trac8611_cached_method_overhaul-fixed.patch.gz Done. |
comment:20
Replying to @loefflerd:
Thank you! |
Merged: sage-4.6.2.alpha2 |
comment:22
For the record, a related thread: |
There are a number of inefficiencies in the critical path (i.e., the code path when values have already been cached) that are addressed in this patch.
PS:
The latest patch does in fact much more: Both the critical and the non-critical path are improved, using various tricks.
CC: @novoselt @williamstein
Component: misc
Keywords: cached method
Author: Jason Grout, Simon King
Reviewer: David Loeffler
Merged: sage-4.6.2.alpha2
Issue created by migration from https://trac.sagemath.org/ticket/8611
The text was updated successfully, but these errors were encountered: