We will have lost a small amount of speed in some places in gcd and xgcd and gained a little in others.
This is a compromise, as I decided to stop using mpn_basic_gcd and mpn_basic_gcdext. Currently we still have them in the codebase, but I don't believe they are hooked up to anything now. Also, we still tune GCD_ACCEL_THRESHOLD which is not used by the current code, so this could be removed. The gcd and xgcd code could use a radical clean up. I am sure that it could also be sped up quite a bit, just by cleaning it up. Although I actually trust it, it is really in a major mess. A lot of this mess was caused by designing it to work with the old mpn_basic_gcd and mpn_basic_gcdext. Also, the function mpn_ngcd (in ngcd.h) seems to be a duplicate of mpn_gcd. I think we can probably get rid of it. I'm going to put all this in a ticket for someone to look at when they find the time. Bill. On 12 May 2010 00:40, Bill Hart <[email protected]> wrote: > I've added tuning for gcd and gcdext now. There's actually only two > new tuning values: > > GCD_THRESHOLD > GCDEXT_THRESHOLD > > For machines where these are not defined, relatively good default > values are provided. But we should run make tune and put these two > values in for each of the arches we support. > > I've added tuning values for core2/penryn and k102 already. > > Bill. > > > On 11 May 2010 21:27, Bill Hart <[email protected]> wrote: >> Oh yes, sorry I completely forgot. tests/mpn/t-gcdext.c is the new >> test which checks the normalisation. >> >> Bill. >> >> On 11 May 2010 20:04, Cactus <[email protected]> wrote: >>> >>> >>> On May 11, 7:34 pm, Bill Hart <[email protected]> wrote: >>>> I got the final cases of the xgcd normalisation sorted. The test code >>>> has been run on large sizes for ages and ages and everything now >>>> passes. >>>> >>>> I've also added a number of new tuning cutoffs for GCD and XGCD to >>>> MPIR. However, at this point the code runs much slower than what we >>>> had before. This is nothing to do with the normalisation but the new >>>> tuning cutoffs (it affects GCD and XGCD). I will try to rearrange the >>>> code tonight when I get home to fix this and restore the earlier >>>> performance. The idea is it should run faster, not slower, when this >>>> is done correctly. >>>> >>>> We'll need to tune for all our architectures once this is working. >>>> >>>> As for a release, is there anyone who would like to do (or learn how >>>> to do) an MPIR release. It is relatively straightforward and I can >>>> explain it in detail. We would like a volunteer to do this for this >>>> release cycle as it is very bad practice to have a single person in >>>> charge of all releases. If anything happens to that person, or they >>>> become unavailable, the project grinds to a halt. >>>> >>>> Please let us know if you would like to volunteer for this. I'll >>>> advertise again in a new thread once I have the tuning sorted, at >>>> which time it will be time to start the release process (for this mini >>>> release). >>>> >>>> For Brian, there should be no changes to the Windows code, except for >>>> the new tuning cutoffs. But these are not available yet. I'll let you >>>> know when they are done for linux. >>> >>> There appears to be a new test as well - is this correct? >>> >>> Brian >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "mpir-devel" group. >>> 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/mpir-devel?hl=en. >>> >>> >> > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. 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/mpir-devel?hl=en.
