I have now tuned on the following architectures: core2, penryn, k102, netburst, k8, k10, bulldozer, westmere, sandybridge, piledriver, nehalem, core2, ia64.
I don't have tuning values for: x86 (any kind), bobcat, atom, arm, mips32, mips64, sparc32, sparc64, ppc32, ppc64. If anyone can contribute any of the above, please do. Bill. On 20 March 2014 21:41, Bill Hart <goodwillh...@googlemail.com> wrote: > I now fixed the bug which was causing the fft tuning code to crash on some > machines. In theory it could also cause a crash in the fft on those > machines. But in practice the FFT is never used in that range. So it's a > theoretical bug only, in theory. > > Bill. > > > On 20 March 2014 16:33, Bill Hart <goodwillh...@googlemail.com> wrote: > >> I have now added all the tuning code we need for the release. >> >> I just need to fix the fft tuning code on systems on which it still >> crashes. >> >> Bill. >> >> >> On 20 March 2014 00:54, Bill Hart <goodwillh...@googlemail.com> wrote: >> >>> I meant to say, "Today I finally fixed mpn_mulmod_2expp1 to use >>> the Nussbaumer trick in the FFT region". >>> >>> >>> On 20 March 2014 00:44, Bill Hart <goodwillh...@googlemail.com> wrote: >>> >>>> Today I finally fixed mpn_mulmod_2expp1 to use the FFT wraparound trick >>>> in the FFT region. >>>> >>>> As mpn_mulmod_bnm1 uses this function, this means that GMP-ECM will now >>>> be able to use MPIR more efficiently. >>>> >>>> I think that much of our mulmod_2expp1 and mulmod_bnm1 code needs >>>> rewriting, but this can wait until someone can do it properly. >>>> >>>> I also added some tuning for the new division functions. I'm not >>>> convinced it is picking the right thresholds, based on my own timings. But >>>> it's coded correctly, so there's nothing I can do about it. At least the >>>> division code doesn't seem to slow down with the new tuning values. >>>> >>>> Tomorrow I will add some tuning functions for the new GMP combinatorics >>>> functions that we added. I will also fix a bug in the fft tuning code which >>>> causes it to crash on some systems. >>>> >>>> This should hopefully complete all the new features for MPIR 2.7 and we >>>> can move on to closing all the open tickets for the release. >>>> >>>> I have essentially until the end of next week to do as much as I can, >>>> after which I will have to work weekends if it isn't done. >>>> >>>> After tomorrow we will need to retune MPIR on as many platforms as we >>>> can. Help with that would be appreciated. >>>> >>>> By the way, after May 31st we'll lose access to about half the machines >>>> we build on, due to one of the build farms closing down. So if anyone has >>>> access to lots of heterogeneous hardware with linux, git and recent gcc on >>>> it, please let us know. >>>> >>>> Bill. >>>> >>> >>> >> > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
