To enable CADO-NFS, uncomment the cadoMsieve option, and fill in cado_dir/convert_poly_path accordingly.
During GNFS, CADO-NFS is used for both polysearch and sieving. During SNFS, the polynomial is fed into CADO-NFS. However, we don't change the sieving parameters, as that appears to slow down sieving.
It should be capable of resuming sieving progress, but there might be bugs that I didn't find.
You might observe that the relation number magically increased after a reload. This is because it doesn't consider newly added free relations while calculating current_rels.
There are many changes thanks to a newline change in cmdOptions.{c,h} (ece0187). I'm mitigating this by creating .git-blame-ignore-revs, which will make the blame ignore that commit. I, unfortunately, can not do the same to the Files changed interface.
It lacks Windows support, as I utilized some shell commands such as gunzip.
https://www.mersenneforum.org/showthread.php?t=28030 In small numbers (Difficulty 100~110,) it can achieve >10% speedup on both GNFS/SNFS.
To enable CADO-NFS, uncomment the cadoMsieve option, and fill in cado_dir/convert_poly_path accordingly. During GNFS, CADO-NFS is used for both polysearch and sieving. During SNFS, the polynomial is fed into CADO-NFS. However, we don't change the sieving parameters, as that appears to slow down sieving.
It should be capable of resuming sieving progress, but there might be bugs that I didn't find. You might observe that the relation number magically increased after a reload. This is because it doesn't consider newly added free relations while calculating current_rels.
There are many changes thanks to a newline change in cmdOptions.{c,h} (ece0187). I'm mitigating this by creating .git-blame-ignore-revs, which will make the blame ignore that commit. I, unfortunately, can not do the same to the Files changed interface.
It lacks Windows support, as I utilized some shell commands such as gunzip.