On Nov 30, 2006, at 6:59 PM, David Harvey wrote: > On Nov 30, 2006, at 9:40 PM, William Stein wrote: > >>> If it's 1MB per ring, then I only have to be >>> working modulo 500 or so integers simultaneously --- not at all a >>> far- >>> fetched situation --- before my typical desktop PC runs out of RAM. >> >> We could only automatically cache up to 50 rings, say. If the user >> *wants* caching, they can always explicitly ask for it, and if they >> don't they can always explicitly ask not to have it. >> >> sage: Integers(97, cache=False) >> sage: Integers(97, cache=True) >> >> if you are explicitly about casting then either option should >> be respected. If you don't specify anything for cache, it could >> use some rules, such as suggested above. > > OK, I could live with that.
I have to agree that caching a couple MB here, a couple MB there could get expensive quickly for many people's home computers, so it should be done with care. Somewhere we tracked down that a single IntegerMod was (I think) 28 bytes on a 32-bit machine. Including the pointers, that's 32KB (extra) for Integers(10^4), and a total of 16MB for every ring up to 10^1000. Somewhere, however, you'll always want to cache (e.g. integers mod 3...) I think caching up to a certain size is conceptually easier than keeping track of caching only on the first, say, 50 created. Definitely have a flag. >> On the other hand, if you create a large number of elements modulo >> one >> integer with the caching you won't run out of memory, whereas without >> it you might very well run out. > > I'm not so sure about this. If you cache, then every IntegerMod is a > Python object containing a pointer that points to the cached object. > If you don't cache, then every IntegerMod is a Python object > containing a single machine word describing which element it is. Am I > missing something here? Have I been spending too long away from > python/pyrex? No, the way caching is working here is that arithmetic operations return the pre-created Python object as the result. E.g. sage: R = Integers(389) sage: R(2)+R(3) is R(1)+R(4) True >>> We got some of the way towards solving this problem at SAGE >>> Days 2. Much of the work has been done for the Integer class. I >>> hope >>> that someone can put some effort into generalising and improving >>> those efforts. I don't have the time right now to work on this. >> >> I pushed that same work through to most other compiled classes. >> E.g., Python's own ints with their caching etc., do the benchmark >> mentioned above in 0.70 seconds, so now SAGE's object creation isn't >> that far off from Python's own built-in optimized object creation. > > I didn't realise that work had already been done. Thanks for doing > that! > > It's really incredible that MAGMA goes faster than python ints here. > From memory, at sage days 2, our Integer stuff was still a factor of > 7-10 away from python ints, at least for addition. > > David > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
