OK, page updated.
Many thanks to all for your help !

Note : I don't specify merges for sequences that end on a prime number, like 29^50. Because anyway, all the sequences that end merge with another one towards the end, as Happy5214 says in post #613 !

[QUOTE=richs;556978]Taking 439^20 at i2157.[/QUOTE]

439^20 is now at i2253 (added 96 iterations) and a C128 level with a 2^9 * 3^2 driver, so I will drop this reservation. The remaining C102 term is well ecm'ed and is ready for siqs.

Taking 439^40 at i39.

[QUOTE=richs;559060]439^20 is now at i2253 (added 96 iterations) and a C128 level with a 2^9 * 3^2 driver, so I will drop this reservation. The remaining C102 term is well ecm'ed and is ready for siqs.

Taking 439^40 at i39.[/QUOTE]
SIQS for a C102? The "official" cutoff (according to yafu) on my Linux Core 2 box is 98-99 digits, though I've noticed recently that 99-digit GNFS jobs actually take [i]less[/i] time than 98-digit SIQS jobs. :confused2:

In actual progress news, I'm finished with 21^82 and 21^84, and those are released.

[QUOTE=Happy5214;559320]SIQS for a C102? The "official" cutoff (according to yafu) on my Linux Core 2 box is 98-99 digits, though I've noticed recently that 99-digit GNFS jobs actually take [i]less[/i] time than 98-digit SIQS jobs. :confused2:[/QUOTE]

Using the tune function of yafu on my i3 results in a siqs/gnfs crossover at C104 for that laptop. On my i7, the yafu crossover is C106.

The table elements for base 72 through exponent 88 are complete (although the table is not shown due to corrupted sequences within the db).

For all of the corrupted sequences, index 1 and beyond has been entered into the db, so when the initial terms are fixed all will be available as normal. In the meantime, for anyone maintaining a local set of .elfs for their study, I have attached a correct set of the corrupted sequences.

[QUOTE=richs;559327]Using the tune function of yafu on my i3 results in a siqs/gnfs crossover at C104 for that laptop. On my i7, the yafu crossover is C106.[/QUOTE]

Those cutoffs are nuts! maybe try timing a C102 both ways to see if tune is accurate? Is gnfs via factmsieve.py?

For CADO vs siqs, my cutoff is 93 digits. CADO is over twice as fast as yafu by 99 digits.
Doesn't help windows users, alas.

Yafu siqs is very fast / fine tuned. Except for very old versions and CPU, the cutoffs were always around 100 digits, a bit over. I also get 103..106 depending on what else the computer does.

[QUOTE=VBCurtis;559333]CADO is over twice as fast as yafu by 99 digits.
[/QUOTE]


Wow, really? Is there anything in your setup that makes it so, or do you think that's true across the board?

[QUOTE=Mr. Odd;559337]Wow, really? Is there anything in your setup that makes it so, or do you think that's true across the board?[/QUOTE]

I hand-tuned the CADO params files for speed- they're posted in the CADO subforum [url]https://mersenneforum.org/showthread.php?t=24274[/url]. Most of my files are 20-30% faster than the factory defaults, but the C100 file in particular is slow by default (quartic poly, for one). I think non-hyperthreaded machines will not be quite as fast running CADO as HT-enabled.

Similar work can be done for factmsieve/GGNFS, particularly on the relations-wanted values that trigger the first filtering run. I haven't run factmsieve in quite a while, but I think the stock settings filter a whole bunch of times, stalling sieving quite a bit. Edit- I've never run GGNFS controlled by Yafu, so I can't comment on its efficiency.

My best CADO C100 timing is a tick under 6 minutes wall-clock time, on a single-socket Xeon 12x2.5Ghz. On an haswell-i7 (6x3.3ghz), I have 9.5 minutes for C101 on CADO.

On C93, I have 226 sec on CADO, 229 sec on siqs (both 12-threaded on 12 cores).

EDIT: As noted in the above-referenced thread, Skylake-yafu using AVX-512 is much faster, with a crossover to CADO around 97-98 digits.

Yafu siqs on 93 digit semiprime (p47*p47) on 10 cores, 10 threads, ~84k relations needed, 166 seconds.

NFS on the same number is about [STRIKE]30[/STRIKE] 40 seconds slower.

[QUOTE=EdH;559331]The table elements for base 72 through exponent 88 are complete (although the table is not shown due to corrupted sequences within the db).

For all of the corrupted sequences, index 1 and beyond has been entered into the db, so when the initial terms are fixed all will be available as normal. In the meantime, for anyone maintaining a local set of .elfs for their study, I have attached a correct set of the corrupted sequences.[/QUOTE]


Thanks a lot Ed !

:smile: