Oh, and here are your factors ;)

PRP54 = 365849225019517205174093887335805855153215240857413517
PRP41 = 19321365350538234231209779178972686869757

Thanks for the factors, Ben. I look forward to testing the next version.

Rich

Can the msieve QS code benefit from your fixes?

[QUOTE=jasonp;238448]Can the msieve QS code benefit from your fixes?[/QUOTE]

No, this was something I bolted on. The fix just gets rid of some of the original awkwardness that I created when integrating your postprocessing code :smile:.

Has anyone done any benchmarking to determine what composite size is the right switchover point from YAFU SIQS to ggnfs is with YAFU v1.20?

The question is complicated on a multi-core system where YAFU's instant use of all threads vs. the single-threaded polyfind step means it sometimes wins in wall-clock time but loses in CPU time. But here I'm asking just about single-threaded performance.

Aliqueit recommends using ggnfs for 89 digits and above, but I just tried a couple c90s and found YAFU to be 3.3x faster both times. I haven't yet zeroed in on the break-even point, but was wondering if anyone else has.

P.S. I saw a wicked speedup on i7 with version 1.20 -- nice work, BB!

[QUOTE=bchaffin;238514]Has anyone done any benchmarking to determine what composite size is the right switchover point from YAFU SIQS to ggnfs is with YAFU v1.20?

The question is complicated on a multi-core system where YAFU's instant use of all threads vs. the single-threaded polyfind step means it sometimes wins in wall-clock time but loses in CPU time. But here I'm asking just about single-threaded performance.

Aliqueit recommends using ggnfs for 89 digits and above, but I just tried a couple c90s and found YAFU to be 3.3x faster both times. I haven't yet zeroed in on the break-even point, but was wondering if anyone else has.

P.S. I saw a wicked speedup on i7 with version 1.20 -- nice work, BB![/QUOTE]
There is no definitive line as each pc is different. Operating systems also make a huge difference as ggnfs doesn't get any improvement from running 64-bit windows over 32-bit while it does for 64-bit linux.

[QUOTE=bsquared;238403]I've verified the problem, and I have a fix. This fix drastically reduces the amount of memory consumed during post-processing, which was a problem noted in a different thread. 32bit system should now be usable for larger problems and not limited by memory during post-processing.

I'll try to get the fixed version posted in the next day or so.[/QUOTE]

Ok, I've posted binaries on my [URL="https://sites.google.com/site/bbuhrow/"]website [/URL]as release 1.20.1.

Let me know if anyone is still seeing problems.

- ben.

[QUOTE=bchaffin;238514]Has anyone done any benchmarking to determine what composite size is the right switchover point from YAFU SIQS to ggnfs is with YAFU v1.20?

The question is complicated on a multi-core system where YAFU's instant use of all threads vs. the single-threaded polyfind step means it sometimes wins in wall-clock time but loses in CPU time. But here I'm asking just about single-threaded performance.

Aliqueit recommends using ggnfs for 89 digits and above, but I just tried a couple c90s and found YAFU to be 3.3x faster both times. I haven't yet zeroed in on the break-even point, but was wondering if anyone else has.

P.S. I saw a wicked speedup on i7 with version 1.20 -- nice work, BB![/QUOTE]

I did a while back, maybe around 1.15 or so. I found that the crossover was at 88 digits on a linux64 system (which can take advantage of the faster ggnfs sievers), and 95+ digits on windows 64bit. Didn't test 32 bit windows, but I'd suspect its between 90 and 95 digits (because yafu is slightly slower on 32bit, but ggnfs is mostly the same). Since 1.20 is faster, especially on 64 bit windows systems, the crossover may be higher yet, but can't give an exact figure.

I was using the CPU poly select functionality of msieve (probably 1.43), not the GPU, which may also change the crossover.

p.s. thanks for the comments!

[COLOR=#000][COLOR=#000]Advice please! [/COLOR]Which startup options YAFU?
C155
how to use multiCPU?
Turn off the electricity. How to resume work from Stop?
THANK YOU.[/COLOR]

[QUOTE=bsquared;238538]Ok, I've posted binaries on my [URL="https://sites.google.com/site/bbuhrow/"]website [/URL]as release 1.20.1.

Let me know if anyone is still seeing problems.

- ben.[/QUOTE]

With 1.20.1 I get an error looking for the libgmp.so.1 shared library (on linux, obviously). I also notice that the executable is much smaller than 1.20. Did you maybe link earlier versions statically and this one dynamically? Thanks!

[QUOTE=bchaffin;240321]With 1.20.1 I get an error looking for the libgmp.so.1 shared library (on linux, obviously). I also notice that the executable is much smaller than 1.20. Did you maybe link earlier versions statically and this one dynamically? Thanks![/QUOTE]

1.20.1 is linked with GMP-ECM 6.3, which itself was built with GMP-5.0.1. 1.20 on the other hand was built with GMP-ECM 6.2.3 and GMP-4.2.3. That's the only difference I can see. Both yafu versions were statically linked to libecm.a. All of the above were built on a RH Enterprise Linux 5 box with gcc version 4.1.2.

[edit]
I see that there are different versions of libgmp.so.*, which appear in the gmp/lib/ folder, between the different versions of GMP. So even though libecm is linked statically to yafu, the libecm library in turn probably depends on different dynamic libgmp libraries. I could provide you with the GMP-5.0.1 libgmp.so.10 and libgmp.so.10.0.1 files if you like.