How about we cut out the cpu's that haven't been tested for x years say. If we are going to rewrite/reorganize the mpn layer , then only the modern cpus and C version will be tested anyway.
On Wednesday 25 March 2009 16:38:28 Bill Hart wrote: > One thing we could do is remove support for chips with a "rolling > wall". If the manufacturing date for that architecture is more than > 10, 15 or 20 years ago, say, we could remove support for it. > > Funnily enough, this may not cut much out. The Intel 80386 for example > ceased to be made in September 2007!! Perhaps if we take the 21 years > of manufacture for this CPU as a benchmark, that would mean we cut out > any CPU's which were first manufactured 21 years or more ago, i.e. > before March 1988. > > Often military, aerospace and embedded applications see the lifespans > of chips hyperextended. > > Perhaps, given that MPIR will still run on them, with C support only, > we can afford to have a more recent wall, say 15 years ago. That would > cut out all 80486's, some pentiums, but not pentium pros, etc. > > Bill. > > 2009/3/23 Jason Moxham <ja...@njkfrudils.plus.com>: > > On Monday 23 March 2009 16:45:53 Bill Hart wrote: > >> 2009/3/23 Jason Moxham <ja...@njkfrudils.plus.com>: > >> > MPFR is based on mpn and mpz , not mpf . > >> > >> OK, I didn't seem to know that. I probably should have though. > >> > >> > I suppose we get remove mpf from the default MPIR build , and only > >> > build mpf if we configure with --enable-gmp-compat which could switch > >> > on all the other old stuff we would like to remove. > >> > >> Would that actually cut down the size of MPIR? > > > > No , it would be bigger and more complex > > > >> I also don't see how say switching off nails and mpbsd, etc, would > >> actually save development effort. If someone types --enable-gmp-compat > >> then all that is going to have to be there (and work) anyway. > >> > >> Bill. > > > > What about some of the old cpu archs , mpir would still run on them but > > just in C > > > >> > On Monday 23 March 2009 16:18:56 Bill Hart wrote: > >> >> Hi Mariah, > >> >> > >> >> This would make MPIR unusable in Sage as a drop in replacement for > >> >> GMP, and it would prevent people from using MPIR instead of GMP as a > >> >> base for MPFR. > >> >> > >> >> However, if MPFR becomes independent of the mpf layer in GMP, as I > >> >> suspect it may in the future, then it is a possibility worth > >> >> considering. Though I'd still be worried about packages which want to > >> >> use the mpf layer from GMP and use MPIR as a drop-in replacement. > >> >> > >> >> Bill. > >> >> > >> >> 2009/3/23 Mariah <mariah.le...@gmail.com>: > >> >> > Bill, > >> >> > > >> >> > As a suggestion on something that could be removed from > >> >> > MPIR, had you considered removing the mpf code? I was > >> >> > under the impression that MPIR was going to concentrate on > >> >> > multiple-precision integers and rationals, and > >> >> > leave multiple-precision floating-point to MPFR. > >> >> > > >> >> > Mariah > >> >> > > >> >> > On Mar 20, 11:30 pm, Gonzalo Tornaria <torna...@gmail.com> wrote: > >> >> >> On Fri, Mar 20, 2009 at 11:46 PM, Bill Hart > >> >> >> <goodwillh...@googlemail.com> > >> > > >> > wrote: > >> >> >> > I suppose it's just aggregation. > >> >> >> > > >> >> >> > Maybe we need to get rid of the bit that says, "overall licensed > >> >> >> > LGPL". Is that still permitted, when some component of the > >> >> >> > distro is GPL? > >> >> >> > >> >> >> Sounds like a good idea. > >> >> >> > >> >> >> > Actually the reason for me wanting to perhaps get rid of the > >> >> >> > demos was more to do with the fact that I don't know anyone who > >> >> >> > uses them. Very clear examples in the documentation would > >> >> >> > probably be much more useful. > >> >> >> > >> >> >> I haven't looked at the demos, but I did want to use the benchmark > >> >> >> and I didn't get to it until your posted howto (not that it was > >> >> >> that hard, but I was lazy). I expect more people will use it if > >> >> >> "make bench" just works. > >> >> >> > >> >> >> I'm not arguing to keep the demos, nor I am saying that benchmark > >> >> >> code should not be rewritten and expanded. But just not because of > >> >> >> licensing. > >> >> >> > >> >> >> > Anyhow, it's no big deal. Just an idea. I suppose the thing that > >> >> >> > set off that thought process for me was Brian saying it took > >> >> >> > forever to check out MPIR via his internet connection. We are > >> >> >> > carrying some fat. There's no reason to not have the demos on > >> >> >> > the website. Can't come up with as clear a case for leaving them > >> >> >> > in the library source. > >> >> >> > >> >> >> Sounds fair if demos are indeed big, I have no idea how much space > >> >> >> they take (otoh, I think Brian was updating the root of the svn > >> >> >> repo instead of just trunk). The benchmark code is about 6kb > >> >> >> compressed... not too bad. > >> >> >> > >> >> >> Gonzalo > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
