I did lots of experimenting. If I really go crazy with optimisation I can get it down to about 1.93s. About another 0.05s is just taken up figuring out which case we are in (e.g. everything fits in one limb, or two limbs, or whatever). I could duplicate the code multiple times for the different cases and save that time.
In the end, I decided I couldn't live with all the optimisations. Many of them are stupid things you have to do because C compilers can't rely on variables not changing between uses. Apparently Fortran doesn't have this problem and is one reason why a lot of numerical people use it. There are lots of optimisations Fortran compilers can apply that C compilers can't. The other optimisations had to do with branch optimisation. Anyhow, I decided to live with just slightly less optimisation and slightly neater code. So now the time is at about 2.0s. It handles arbitrary sized coefficients, but only exponents which can be packed into a single limb. I won't have time to extend it to the case of larger exponents just now. The times are good enough for me. On that 2.0s very sparse benchmark, Magma takes about 11s and Sage about 87s on my machine (K102). Bill. On 15 May, 03:51, Bill Hart <goodwillh...@googlemail.com> wrote: > 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 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
