Yafu

[Karl M Johnson]

I vote for dropping non-SSE2 code.
Since SF already hosts previous versions for ye olde CPUs, it looks like a very sober decision.

[firejuggler]

Voting for the drop of non SSE2 code.
Perhaps rename the Old 'yafu' as ' Legacy -yafu' or a similar name.

[bsquared]

Originally Posted by EdH

I have run into the problem of non-SSE2 AMD CPUs with my ancient systems. Oddly, one of them is currently running circles around a similar Intel that has SSE2.

Anyway, why not work on the leading edge, drop support for anything that is hindering, but leave available in an archive somewhere, earlier versions that can be used by those of us who enjoy our steam-driven machines?

I would not mind using an earlier version instead of the latest and greatest, especially if it's due to my tardiness in upgrading. For some, the restrictions might even be the drive to go ahead and upgrade, instead of procrastinating.

Sourceforge has previous versions available already (as Karl mentioned), so that's not a problem. In fact, you may want to be using them anyway; some of the more recent changes, while much faster on SSE2 capable systems, may actually be slower for older systems (please test first on your system).

However since a merger of yafu and msieve is on the horizon, I'll probably wait to do any removal of the generic branch until then.

Thanks for all of the feedback.

[bsquared]

Originally Posted by Andi47

Yes, there have been two of them. I deleted one (leaving one newline) - I will see what happens when aliqueit.exe invokes yafu next time.

Is this still an issue? Nothing looks wrong with the .ini file... can't say for sure why you saw that error. Removing extra newlines was a good idea.

[Andi47]

Originally Posted by bsquared

Is this still an issue? Nothing looks wrong with the .ini file... can't say for sure why you saw that error. Removing extra newlines was a good idea.

No, it works properly now.

BTW: Tiny Suggestion for yafu (I use it mostly for aliquot sequences, where yafu is invoked by aliqueit.exe): When yafu is in the ECM pretesting stage, it prints the digit count (e.g. "ecm: 402/402 curves on C109 input") to screen. While in nfs stage, yafu prints the number itself to screen, but not the digit count. (I don't want to count 100+ digits on the screen).

Can you please add the digit count to the screen output in the nfs stages, especially sieving and postprocessing?

[Andi47]

Is there a way to reduce ecm-pretesting before gnfs? It seems, that e.g. for a c119, ecm-pretesting takes quite a bit longer than gnfs.

I used to do ~t35 around c113 and ~1*t40 around c125-127, so 450% of t40 seems way too much for me (especially if it takes longer than the gnfs; I use the 6 threads for both, ecm and gnfs), so I want to reduce the ecm pretesting by

the yafu.ini file contains the line

ecm_gnfs_ratio=0.25

Is this the line what I am looking for? would setting it to - say - somewhare between 0.1 and 0.15 do the trick?

[yoyo]

Hello,

the yafu1.28.zip contains 2 different win32 versions:
yafu-64k-win32.exe and
yafu-32k-win32.exe
What is the difference?

yoyo

[Jeff Gilchrist]

Originally Posted by yoyo

the yafu1.28.zip contains 2 different win32 versions:
yafu-64k-win32.exe and
yafu-32k-win32.exe
What is the difference?

Different window/buffer sizes. I believe AMD based processors are faster with the 64k version and Core2 based ones with 32k but not sure about the latest Core iX processors from Intel.

Jeff.

[bsquared]

Originally Posted by Andi47

Is there a way to reduce ecm-pretesting before gnfs? It seems, that e.g. for a c119, ecm-pretesting takes quite a bit longer than gnfs.

I used to do ~t35 around c113 and ~1*t40 around c125-127, so 450% of t40 seems way too much for me (especially if it takes longer than the gnfs; I use the 6 threads for both, ecm and gnfs), so I want to reduce the ecm pretesting by

the yafu.ini file contains the line

ecm_gnfs_ratio=0.25

Is this the line what I am looking for? would setting it to - say - somewhare between 0.1 and 0.15 do the trick?

Yes, reducing the ecm_gnfs_ratio will decrease the amount of time spent in ecm prior to gnfs. You could also try running tune(), which is designed to tailor the cutoff point for your particular computer. If you've already run tune and are seeing this poor of pretesting performance, then PM me and maybe I can diagnose what's going on.

@ yoyo and Jeff
Yep, 64k still seems to be slightly faster for AMD cpu's. 32k is faster for Intel cpus, including the i series stuff.

[Andi47]

Originally Posted by bsquared

Yes, reducing the ecm_gnfs_ratio will decrease the amount of time spent in ecm prior to gnfs. You could also try running tune(), which is designed to tailor the cutoff point for your particular computer.

Thanks I will eventually try some value around 2.0

Tune(): I guess, I start yafu first by typing "yafu" in the command line, and then type tune()? Or should I rather type "yafu -tune()"?

[yoyo]

Just type
yafu tune()

yoyo