On Dec 1, 2006, at 12:29 AM, William Stein wrote:
>> 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. > > Python ints: > > (1) Have a custom optimized allocation scheme, which e.g., > allocates > a block of 1000 ints all at once, then fills them in, then > allocates > another such block when there are > 1000 ints all in use at > once. > (2) it never returns any memory allocated for ints (saving it for > future ints). > > In short, Python int creation is very fast partly because lots and > lots > of caching is used, similar to the sort of caching that is being > proposed > for Z/nZ. (Actually it's 1000 bytes worth, not 1000 ints worth, but whatever.) Yeah, Python int handling is very clever. I read over intobject.c again this morning, surprisingly I think I understood it much better than when I studied it at SAGE days 2. > It might be interesting to copy intobject.c from the Python source > code > to some other file, and adapt it to use GMP ints as the underlying > data > structure instead. I wonder what would happen? Did you consider > doing > that at the coding sprint? (I'm not suggesting replacing Python's > ints > by GMP ints, but making a new int type that happens to quickly benefit > from all the work that went into making the Python int type fast.) I think maybe it can be done. We thought about it but didn't actually do it at the coding sprints, we were too busy getting our head around all the stuff that was new to us back then. There are a few issues: (1) I don't have time to work on this now :-) (2) There is the problem of mpz_t allocation time too, which is an independent but related problem (3) If we really did want to use a python-int-like allocation strategy for SAGE Integers, it would be difficult to reconcile that with a pyrex implementation. I haven't thought about it too carefully, but I think what we would need to do is write a few functions in pure C, and then make some of Integer's tp* slots point to those functions, to override pyrex's implementations. It would be a bit fragile. One difficulty is that I don't know exactly when those function reassignments would take place, and maybe there already would be Integer objects hanging around.... ugh. David --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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/ -~----------~----~----~----~------~----~------~--~---
