Actually I wasn't allocating them in slabs. I had my threadsafe version of the flint integer format turned on. The other version allocates mpz's in slabs, but was broken. So.....
.... having now fixed that. I do get the time down to about 2.1s on sage.math. However, that's not noticeably faster than the threadsafe version at this point. Probably it is just some overhead in the way I'm dealing with mpz's. That's pretty much set in stone now, as numerous FLINT modules are based on it. So probably I can't do anything about it. I'll have a little bit more of a thing tomorrow and see if there is anything else that I can come up with, but I suspect there isn't much else to try now. At least it gets quite close to these low times. Bill. On 14 May, 20:50, Roman Pearce <rpear...@gmail.com> wrote: > On May 14, 9:54 am, Bill Hart <goodwillh...@googlemail.com> wrote: > > > On the other hand, I am unable to replicate the very sparse benchmark > > unless I assume the result will fit in 2 limbs and allocate all the > > output mpz's in advance, etc. Then I can basically replicate it. If I > > use my generic no assumptions code it takes about 3s. I don't think I > > can improve that much if at all. > > Are you allocating the coefficients one at a time? In sdmp this is > amortized by allocating blocks of memory at a time. > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group athttp://groups.google.com/group/sage-devel > URL:http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
