Discussion related to cado-nfs

[paul zimmermann <Paul.Zimmermann@inria.fr>]

       Hi Guy,

> From: Guy - <pleasechoose@hotmail.com>
> Date: Thu, 6 Apr 2017 07:51:54 +0000
> 
> Hi,
> 
> I'm trying to run cado on RSA-640 (193 digits), I have a server with 32 
> cores and 32GB RAM.
> 
> I've noticed that when sieving the las process takes approx. 3.3GB, this 
> limits the sieving to 8-9 cores.
> 
> When running cado-nfs.py the configuration is chosen automatically to the 
> rounded-up matching number (params.c195), and the sieving region is defined 
> to tasks.I = 15
> 
> I also noticed that params.c190 (closest rounded down matching number) 
> defines tasks.I = 14
> 
> 
> According to the parameters documentation (params.c90):
> 
> Increasing I by 1 multiplies the amount of required RAM for the siever by a 
> factor of 4.
> 
> 
> As expected, decreasing I to 14, reduces the amount of ram to approx. 1GB, 
> which allows me to run sieving on about 30 cores.
> 
> 
> My questions are:
> 
> 1. Why was 15 chosen? what is the penalty for choosing 14 instead? I can 
> see that each workunit sieves less (~7000 relations instead of ~17000),

I=15 was chosen since it is close to optimal for this number size
(assuming no memory limit).

> 2. What happens if you decrease task.I during a run? (after some of the 
> relations were gathered with I=15) I've noticed that the polynomial 
> MurphyE's score is affected by reducing to tasks. does it mean that this 
> polynomial is not necessary the best with the new chosen I?

normally changing I during a factorization should not affect the 
factorization,
however we do not test this in our regular tests.

> 3. Decreasing to 14 improved sieving by 20% (~230 rels/min instead of ~190 
> rels/min)

however since you get less relations per special-q range (7k instead of 17k)
you'll have to sieve for larger special-q's, where the rate of relations per
second will decrease. Also if you decrease I too much, it can happen that you
do not get enough relations, even with very large special-q's.

Another solution is to use 4 threads instead of 2 in las
(tasks.sieve.las.threads=4). This will decrease the average memory
usage per thread, thus you can use more cores of your server.

Best regards,
Paul Zimmermann

PS: note that RSA-640 was already factored in 2005... If you want to factor
numbers in this range, there are some "Smaller-but-Needed" candidates in the
Cunningham project: https://homes.cerias.purdue.edu/~ssw/cun/want131 (please
contact Sam Wagstaff to reserve any of those)