On 24 January 2018 at 16:45, Brian Gladman <b...@gladman.plus.com> wrote:
> On 24/01/2018 12:15, 'Bill Hart' via mpir-devel wrote: > > [snip] > > What has just occurred to me is that we can arrive at a 'perfect' > MPIR > > integer API by reversing how the doubles and integers are returned: > > > > mpir_si mpz_get_2exp_d(double *r, mpz_srcptr src) > > mpir_si mpf_get_2exp_d(double *r, mpz_srcptr src) > > > > If these returned a 64 bit integer and I had code like: > > > > long s = mpz_get_2exp_d(r, src); > > > > would this automatically cast down to the shorter length integer? I'm > > not sure I see why this is better than the current situation? > > The fix doesn't do a lot here but it helps in two other situations. > > With what we have now, when a 64-bit value is stored via a pointer into > a 32-bit location, the upper 32-bits will overwrite data in adjoining > locations and cause erroneous results and/or crashes. > > Also, when a 32-bit value is stored via a pointer into a 64-bit > location, the upper 32-bits won't be overwritten so whatever was in the > top 32-bits will remain causing the value to be incorrect. > > These bugs turn up not infrequently on Windows x64 and it would be good > to remove them. > > > Well, it is better in the sense that it gives the full 64 bits, which we > > will obviously use in Flint. But does it make writing code any easier? > > Yes in that it will make it easier to write code that doesn't contain > the sort of bugs that we are discussing. > > > Also, any existing code will not be using these and will have to be > > rewritten. Not a big problem for Flint, as you have noted, but maybe for > > other systems? > > Not immediately since I envisage these as functions that are additions > to, rather than replacements of, the existing functions. We might, of > course, remove the older ones later. > > > As the MPIR Windows developer/maintainer, moving to an MPIR API that > is > > pure in respect of integer length is compelling, especially so as it > is > > not hard to achieve at the code level. > > > > But it would seem that making this change won't be possible unless we > > can find a volunteer to do the work that this requires for Linux/Unix > > and for delivering new MPIR distributions. > > > > I very much doubt we will find one. I've been calling for people to > > contribute for years. No one has stepped forward and stuck with it. > > > > It requires a very skilled individual, most of whom are busy with other > > projects. > > > Leaving FLINT on Windows x64 (and other applications that depend on > it) > > reliant on old versions of MPIR and GMP would effectively mean that > it > > would progressively die on Windows since it would not be able to take > > advantage of the work that Jens Nurmann and I have done in adding > > assembler code support for recent Intel processor architectures. > > > > I think MPIR will die on all platforms, in time. The community just > > doesn't have any interest in it. Were the interest there, we'd know by > now. > > > > People only seem keen on fixing it if it stops building. They don't care > > about performance, adding functionality or dealing with tickets that > > aren't immediately breaking their code. > > > It's especially a shame that the work Jens put in still sits in limbo. > > But I just don't have the time to do the testing, profiling and > > integration required. There's a week of work for someone who knows what > > they are doing, or a months for someone who is new to MPIR but otherwise > > very skilled. > > On a more optimistic note, the work that Jens Nurmann and I have done in > adding new assembler code for recent machine architectures is available > for those who are willing to work with the repository version of MPIR. > > And it may well make sense to add the new functions to my repository > anyway as it will at least mean that I can keep the repository versions > of both MPIR and FLINT for Windows x64 in a fully working state (the > FLINT changes needed are very limited as discussed earlier). > Was all Jens' Broadwell optimisation committed. The last I recall we were waiting for someone with a Broadwell to test and see which functions were faster than the current ones. This would have had to be done on a Linux system, since it isn't possible to get reliable timings on a Windows box, unfortunately. Or are you only talking about Skylake and Nehelem, which I think is in MPIR-3.0.0. 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 https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
