On Fri, 01 Dec 2006 05:11:58 -0800, David Harvey <[EMAIL PROTECTED]> wrote: >> 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.)
Thanks for the clarification. > 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. Same here. >> 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. Also -- the work you did there was useful for all of SAGE, since I was able to, e.g., propogate use of PY_NEW all over the place with almost no trouble, for an immediate huge speedup. > There are a few issues: > > (1) I don't have time to work on this now :-) Same here. > (2) There is the problem of mpz_t allocation time too, which is an > independent but related problem. This may be a serious issue. > (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. I'm not opposed to SAGE integers being written entirely in C if that is what it takes. Though I prefer solutions that can work in the context of SageX, since they are much faster to deploy and can benefit more code. Also, maybe the above suggests a way in which SageX could be changed to better accomodate optimization. I.e., there could be a facility for explicitly specifying how tp* slots should be filled in. -- William --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
