On 17 January 2014 12:26, Fredrik Johansson <fredrik.johans...@gmail.com>wrote:
> On Fri, Jan 17, 2014 at 12:00 PM, Bill Hart <goodwillh...@googlemail.com> > wrote: > > Hi all, > > > > as many of you know, I've been planning my time well in advance for some > > time now. This helps with productivity and with general well-being. > > > > To that end, you will find my current schedule below, followed by a > > discussion of aims for mpir and future plans for flint. > > > > --------------- > > > > Jan 20-22: > > * mpfr meeting in Nancy > > > > Jan 23-31: > > * finish paper on bignum division > > > > Feb 1-28: > > * 200-400 lines of code for project with D. Harvey > > * mpir-2.7.0 release > > > > March and following (unscheduled): > > * LLL and HNF > > * asymptotically fast polynomial resultant > > * qsieve > > * ANTIC (number field arithmetic: inversion, division, powering) > > > > ---------------- > > > > Plans for MPIR 2.7: > > > > Below is a list of things that need doing for MPIR. I have placed a > cutoff > > where I think we can get to for the 2.7 release: > > > > * Fix issues reported by many people (I will put up github tickets when I > > return from Nancy) > > * Document and clean up x86_64 assembly code > > * Indent, clean up Jason Moxham's old C code > > * fft versions of mpn_mulmod_bnm1/p1 for gmp-ecm > > * merge toom-6 code from GMP > > * cpuid support for recent Intel/AMD chips > > * update config.guess and friends > > * tuning for new division code > > * support Cygwin64 > > * maintain Windows build scripts > > * support for latest MSVC > > * GMP 5.1.3 compatibility > > > > <CUTOFF -- contributions welcome> > > > > * complete overhaul and documentation of libspeed > > * complete overhaul of tuning code, including fixing it on platforms > where > > it is broken > > * clean up and document the part of the build system that decides whether > > functions such as mpn_preinv_divrem_1 are available or not > > * add new mpir_mullo, mpir_mulhi, mpir_mulmid which yield 2 limb > overflows > > * add montgomery multiplication > > * add a public interface for FFT precaching > > * add a public interface for division with precomputed inverse > > * implement new binary to decimal conversion due to Zimmermann and > Bouvier > > (http://hal.inria.fr/hal-00864293) > > * write a new assembly superoptimiser for x86_64 (to replace the one > Jason > > had) > > * speed up very unbalanced multiplication > > * (assembly) optimise FFT > > * much better developer documentation, esp. mpn interface and how to add > new > > files > > * parallelise FFT > > * update mpirbench > > I look forward to the next version, as the tuning problem for > unbalanced multiplication in 2.6 is a major annoyance. > By the way, did you look at the FFT tuning on Intel processors? I > think I saw smaller speedups on Xeons compared to GMP than those you > reported on AMD processors, at least in some ranges. > Yes, on AMD we combine some of the assembly primitives, which accounts for 5% or so of the speedup. Iterative transforms would help here too. But Intel chips work differently and don't benefit from these combined operations. So I certainly expect this. For very large sizes I would imagine the new FFT is still quite a bit faster than the current GMP FFT. But the difference will be less pronounced. It's probably tuned with AMD caches in mind too. > > > I expect that the final release process will start around Feb 21st. > > > > ------------------------ > > > > Plans for flint-2.5 and following > > > > I haven't scheduled a release date for flint-2.5, nor figured out which > > features should make the release yet. I will do so as my schedule becomes > > clearer. > > > > * make Arb a standard extension of flint (it will still be maintained as > a > > separate library too) > > * make mpfr optional in flint (disabling functionality which requires it > if > > not available) > > These items seem to be mutually exclusive... > No, the idea is only to give the opportunity to build a cut-down flint which doesn't need mpfr, not to remove the requirement for mpfr. It's just that some people are complaining about having dependencies other than GMP, and I can see their point. If they are building a library on top of flint which does no floating point arithmetic, why should they need mpfr. Flint and GMP are already dependencies for them. Why would they want to add more for no benefit whatsoever. > > > * automate figuring out which parts of the C++ wrapper need updating (and > > update them) > > * gcov test coverage > > * valgrind all modules > > * large quadratic sieve > > * APR-CL primality testing > > * LLL and HNF > > * asymptotically fast polynomial resultant > > * faster newton division, including FFT precaching > > * rewrite Bland to use the Generic style generics interface > > * root-finding code (Mike Hansen) > > * use BLAS for matrices over Z/nZ for small n, if available > > * Shoup multiplication interface > > * polynomial factoring over Z (Mark van Hoeij recently announced more > > improvements) > > * better polynomial mullo, mulhi, mulmid code > > * fmpz_mod_mat module (some templating may be in order) > > * clean up documentation formatting > > I also suggest some code reorganisation in the near future: perhaps > structure flint into a smaller number of top-level packages (maybe > something like utils, core/integers, padics (optional?), finite fields > (optional?), interfaces (optional), arb (optional), antic (optional)), > with further submodules. It would be nice if the top-level directory > only contained a handful of logical files and directories. > I don't want to put antic in flint itself. It should remain a separate library. We will want to do things in Antic which we wouldn't do in flint, and flint is already large enough. Arb is different. It covers functionality of NTL and is much more fundamental. Apart from the hit to our sloc, I've pretty much always thought this was a good idea. Restructuring flint might be a challenge due to the .h files. People currently have code which includes certain named .h files. I don't think we should break that (again). On the other hand I can see we could do better with directory structure. As a minimum solution we could implement submodules, e.g. put fmpz_mod_poly_factor as a submodule of fmpz_mod_poly, and things like that. I think the danger with making some modules optional is that we then have to disable functions in other modules which depend on them. Maybe making arb and finite fields optional is feasible though. But padics is not a good candidate. For example, we might eventually combine the p-adic lifting in the p-adic and fmpz_poly modules, which in turn will be used by fmpz_poly_factor. For that reason I don't want to overdo the optional thing. I also like being able to figure out easily where any given module is. Currently I don't have to guess whether it is in core or in some other place. > > Another thing I'd like to do is to move the documentation to Sphinx, > unless people object to this idea. It would take some hours of work to > reformat the documentation, but that could be done one module at a > time (the documentation sources are perfectly readable as plain text). > Sure. So long as the current documentation stays until this is completed. > > > Comments/suggestions/contributions welcome. Some of these could make GSoC > > projects. Any volunteers for mentors? Not sure if we already missed the > > application deadline for this year or not. > > Of course I'll be around. Org applications start in two weeks, I > think, and I hope Burcin has time to apply with lmonade. > > Great. > Fredrik > > -- > > --- > You received this message because you are subscribed to the Google Groups > "flint-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to flint-devel+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/groups/opt_out.
