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. > 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... > * 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. 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). > 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. Fredrik -- 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.
