Potential New Team Aliquot Sequence Project (18528)

[jagotu]

Originally Posted by VBCurtis

If you run linux, I'm happy to help you get CADO going and params edited. I think CADO is about 25% faster than yafu/GGNFS, but that's just a guess. It's not so much faster than runing YAFU is folly, at least below the 160s.

I am using Linux. I actually noticed I have a CADO build from 2020 on the machine, so I guess I can try to just update that. But I was mainly confused about the param improvements etc.

After the default yafu deadline (15 hours on 16 threads), it came up with the following poly:

# norm 1.864542e-14 alpha -7.790576 e 5.755e-12 rroots 1
n: 1426043462513149352725343828346122135124558025180582540209975486916412579335442554643075028986048822653001446339523289767395539874538318883219584088397
skew: 4873964.97
c0: -7702032464013727904646074499263003328
c1: -6599971977986952199257338715048
c2: -4593489433867649139114326
c3: 537224032042179013
c4: 134834027824
c5: 19740
Y0: -148510470184210525642080088739
Y1: 12432880281567133
rlim: 26400000
alim: 26400000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.6
alambda: 2.6

Given the poly record for C150 is 6.74e-12, this doesn't sound completely off, but I'm looking forward to what CADO can produce.

[VBCurtis]

I attach my c150 params here.

I've tested similar settings just once so far, and they required 46 hours to factor a C150 (first digit 8) on a 12-core haswell-xeon-2.5Ghz. Poly select was almost exactly 5% of the total job time, allowing you to extrapolate after poly select to estimate how long the job will take.

My regression expects ~44hr for the sample job, so I made a couple changes after my one test before posting the file. Hopefully I went the right direction!

Edit: You can use the file by replacing the file in cado/parameters/factor/ with this file. Rename to remove the ".txt" first- that is just to pass the forum attachment-filter.

[jagotu]

Originally Posted by VBCurtis

I attach my c150 params here.

I've tested similar settings just once so far, and they required 46 hours to factor a C150 (first digit 8) on a 12-core haswell-xeon-2.5Ghz. Poly select was almost exactly 5% of the total job time, allowing you to extrapolate after poly select to estimate how long the job will take.

My regression expects ~44hr for the sample job, so I made a couple changes after my one test before posting the file. Hopefully I went the right direction!

Edit: You can use the file by replacing the file in cado/parameters/factor/ with this file. Rename to remove the ".txt" first- that is just to pass the forum attachment-filter.

Thanks, I'll run using these params and will see. I'm running on 16 cores of Cascade Lake Xeon CPUs (2.6GHz) (courtesy of leftover azure credits).

EDIT: Reading your message, it seems to me that the 15 hours of 16core polyselect yafu did was a tiny bit overkill. CADO ETAs of polyselect are more in the 2 hours ballpark.

[jagotu]

CADO came up with a sligthly better poly:

n: 1426043462513149352725343828346122135124558025180582540209975486916412579335442554643075028986048822653001446339523289767395539874538318883219584088397
skew: 340540.367
c0: -13937828370359837949600476725853504
c1: -50954052566490822206230114856
c2: 525298205446344715893599
c3: 1736437202523857339
c4: -2200500511872
c5: 1935360
Y0: -97915003859407256007196314734
Y1: 1531204466924584393079
# MurphyE (Bf=2.147e+09,Bg=1.074e+09,area=2.013e+14) = 5.852e-07
# f(x) = 1935360*x^5-2200500511872*x^4+1736437202523857339*x^3+525298205446344715893599*x^2-50954052566490822206230114856*x-13937828370359837949600476725853504
# g(x) = 1531204466924584393079*x-97915003859407256007196314734

The poly select took 96 minutes, so according to the 5% estimate the factoring should take exactly 32 hours, so ETA some 24 hours from now.

[charybdis]

Originally Posted by jagotu

CADO came up with a sligthly better poly:

...

The poly select took 96 minutes, so according to the 5% estimate the factoring should take exactly 32 hours, so ETA some 24 hours from now.

The Murphy-E scores from msieve and CADO aren't directly comparable - in fact this has a slightly worse score than the msieve poly (5.584e-12 according to cownoise.com). But that's not surprising given the msieve poly search was so much longer.

[jagotu]

Well... The sieving finished after some 48 hours, but then CADO ran out of disk space in the duplicate removal phase.

I increased the disk space and thought that restarting the same command will continue the job but nope, it deleted everything.

Or maybe it was because I used the tmp folder to store the data. That was so dumb. I'll rerun it with the msieve poly this time.

[VBCurtis]

We've all learned that /tmp lesson with CADO- I'm extra sad for you that you learned it on a C150.

My lesson was given by a power outage 3 days in to a 4-machine-day job.

[EdH]

Originally Posted by jagotu

Well... The sieving finished after some 48 hours, but then CADO ran out of disk space in the duplicate removal phase.

I increased the disk space and thought that restarting the same command will continue the job but nope, it deleted everything.

Or maybe it was because I used the tmp folder to store the data. That was so dumb. I'll rerun it with the msieve poly this time.

To restart CADO-NFS, you need to look in the .log file for a line that says, "If this computation gets interrupted, it can be resumed with. . .parameters_snapshot.#" Use the highest snapshot available.

The /tmp directory will disappear with a computer reset. But, a new run of CADO-NFS will choose a new random /tmp/name, if not told where. If you had not reset the computer the old /tmp/folder would still be there and the snapshot file would begin at where the interruption occurred. I'm guessing that the memory increase was physical, but if not, you may still have the original CADO-NFS run.

BTW, (some) changes in parameters can be made in the snapshot file, prior to restarting.


Edit: In rereading, I see you increased disk space, not memory, so maybe the original /tmp folder still exists.

[jagotu]

Originally Posted by EdH

The /tmp directory will disappear with a computer reset. [...]

Edit: In rereading, I see you increased disk space, not memory, so maybe the original /tmp folder still exists.

It was an azure VM, which I had to reboot to increase the disk size, which deleted the /tmp folder. So yeah it's gone, but I learned a lesson.

[jagotu]

Factored the C150

Info:Complete Factorization / Discrete logarithm: Total cpu/elapsed time for entire factorization: 2.86374e+06/538.16
11789310602681804082021411295029741905179850745183857921041083704139694914489992339 120960716921713506158744867362986272316460242431288299728492494411423

@VBCurtis would the log files help you with further tuning the c150 params?

[EdH]

Originally Posted by jagotu

Factored the C150

Info:Complete Factorization / Discrete logarithm: Total cpu/elapsed time for entire factorization: 2.86374e+06/538.16
11789310602681804082021411295029741905179850745183857921041083704139694914489992339 120960716921713506158744867362986272316460242431288299728492494411423

@VBCurtis would the log files help you with further tuning the c150 params?

Excellent! Glad to see you made it through after a rough start. Thanks for your help.