Revision 27d6c09fcb49d7af2b09fc974051359aa40359e3 authored by Emmanuel Thomé on 03 December 2015, 15:31:34 UTC, committed by Emmanuel Thomé on 03 December 2015, 15:31:34 UTC
1 parent 0b2ec08
Raw File
NEWS
Main changes between cado-nfs-2.1.1 and cado-nfs-2.2:

* The toplevel scripts (factor.sh, cadofactor.py, wuclient2.py) have
  changed. Now there are only two main scripts to be used by most users:
   - cado-nfs.py
     This combines the roles of the previous factor.sh and cadofactor.py.
     The most basic use is ./cado-nfs.py <N>, and it will factor N on the
     local host. It can also become a server in a multi-host
     computation. See README for more details.
   - cado-nfs-client.py
     This is mostly a renaming of wuclient2.py. This starts a client that
     can contribute to a running computation, possibly on another
     machine.
  By default, factorizations running on the localhost will use all
  available cores.
* Main algorithmic improvements:
  - polynomial selection: algorithm of Bai, Bouvier, Kruppa, Zimmermann
    (Better polynomials for GNFS, 2015) has been implemented.
  - relation collection: multi-level buckets for better handling of
    medium-sized primes; cofactorization strategies à la Kleinjung. Both
    features are experimental, and not activated by default.
  - linear algebra: support for non-binary base field (for dlp),
    including the removal of the overhead due to SMs.
* Main speedups:
  - the creation of the factor base is now multithread.
  - linear algebra speedup taking into account machine topology thanks to
    HWLOC (http://www.open-mpi.org/projects/hwloc/).
  - the square root step is now multithread.
  - default parameters files were optimized for sieving with OPAL/nomad.
* DLP support: now fully functional over prime fields, including the
  descent step. Still requires Magma for a small number-theoretic
  computation at the beginning (dependency will be removed sooner or later).
  See README.dlp for further details.
* In local.sh, the customization of the build_tree using the $up_path
  variable used to be phrased as: build_tree="${up_path}some/sub/path".
  Now it should be build_tree="${up_path}/some/sub/path", as $up_path no
  longer embodies a trailing /
* The polynomial file now supports another format. For giving a
  polynomial, a line like 
    poly0=17,42,34,55
  can be written, to set the polynomial 17+42*x+34*x^2+55*x^3 on side 0.
  The old format with X, c, Y,... is still supported, with c and X for
  side 1 and Y for side 0.
* References to rational or algebraic sides have been reduced (at least
  internally). This means that several parameters have now aliases
  corresponding to sizes. For instance, the parameter -lpb1 for las is an
  alias of -lpba. The common convention is that the rational side (if
  any) is on side 0, but everything will work if a polynomial file is imported
  with the rational side on side 1.
* Various changes in the parameter list for the linear algebra task,
  in particular, the linalg.bwc.mn=... parameter is replaced by 2
  separate parameters for m and n. Also the rhs=... parameter allows
  non-homogeneous system solving (useful for handling SMs with no
  overhead in DLP mode).
* An estimated time of arrival (ETA) is now printed during the polynomial
  selection and sieving steps. It corresponds to the estimate finish time
  of each of those steps (not the full factorization).

Main changes between cado-nfs-2.1 and cado-nfs-2.1.1:

* Added test-case in wuclient2.py for buggy Python MIME encoder to prevent
  data corruption during file upload under future Python versions
* Bug fixes to multi-threading in linear algebra code

Main changes between cado-nfs-2.0 and cado-nfs-2.1:
* Polynomial selection now runs in two separate phases, size optimization
  and root optimization, with improved parameters
* Unit tests added, please run "make check" after building
* Various small speed-ups
* Various bug-fixes
* The wuclient2.py script no longer requires an external download tool
  (wget or curl) to download securely via SSL under Python 2
* better support of DL in GF(p); still not fully automatic, nor
  independent of third-party software. See README.dlp.

Main changes between cado-nfs-1.1 and cado-nfs-2.0:

* the default parameters in the params subdirectory have been improved
* major speedups in the polynomial selection, sieving and filtering steps
* the filtering step produces a smaller matrix (about 5% less rows),
  see http://hal.inria.fr/hal-00734654 for more details.
* the replay step is faster and uses less memory
* fixed bug in the lattice siever (las) on 32-bit computers
* allow compilation on MinGW32. Performance is poor, however. MinGW64 is
  currently not supported
* new cadofactor.py script written in Python, allows larger-scale distribution
  with client/server model
* files used/generated by cado-nfs-1.1 are not entirely compatible with
  cado-nfs-2.0. Relations files are compatible, but for pretty much
  everything else, it is preferrable to start afresh. Likewise,
  command-line options of several binaries have changed.
* implementations of NFS-DL and NFS-FFS (experimental, requires some
  background knowledge to use)


Main changes between cado-nfs-1.0 and cado-nfs-1.1:

* the polynomial selection uses the new algorithm presented by Kleinjung at
  the 2008 CADO workshop (supports multithreading)
* the polynomial selection uses a faster root sieve (rootsieve5)
* the lattice siever (las) supports a larger sieving region (I=16). This is
  useful for integers greater than 200 digits
* minor bug fixes, small speedup in sieving (las) and filtering (purge)
* reorganization of the binaries in the linear algebra step and speedup
  when using many machines with MPI
* new experimental scripts to execute the sieve on a cluster.
  These scripts rely on the OAR job scheduler being used, and exploit its
  "besteffort" mode. Some even more experimental scripts for linear
  algebra are in the development version.
* addition of new parameter files and a few new parameters (cf params.c91)
* the linear algebra step now makes use of dynamically loaded shared
  libraries. This might result in configuration issues, which we hope the
  scripts get it right. See the README file.

back to top