Featured request

[VBCurtis]

Swellman-
In my experience with an i7 laptop, 8 threads is best for ecm and NFS stages. I believe the optimal choice depends only on the hardware setup, so a set of one-time experiments can answer this permanently- no code required.

Also, code such as you request could routinely misoptimize if other processes are intermittently taking up other HT threads- all the more reason to optimize once in controlled circumstances manually. I personally run whatever I wish (LLR, for instance), and then fill up all remaining HT threads with NFS or ecm.

-Curtis

[swellman]

Thanks VBCurtis for your insights. I'll stick with my current strategy of max HT but maybe further explore the effect of the -lathread flag on my i7's factoring performance.

[schickel]

Originally Posted by swellman

Thanks VBCurtis for your insights. I'll stick with my current strategy of max HT but maybe further explore the effect of the -lathread flag on my i7's factoring performance.

For another data point: I have an AMD Phenom II X6 1090, which has 6 physical cores. For LA jobs, the speed ramps up pretty close to linearly until I hit 4 threads; I don't have numbers closeby, but I think I posted some benchmarks which showed that 6 threads is considerably less than twice as fast as 3 threads. There is, however, no slowdown if I run 6 sievers or 6 ECM clients at the same time.

[swellman]

Just want to capture this suggestion for future consideration.

Ben, if you don't have a better estimate, you could use a
size < 0.56*Snfs-diff+30
ad hoc decision boundary. For a better boundary, you could obtain the E-value (internally for the snfs poly) and search a gnfs poly for a short time while comparing the best gnfs E-values and using some heuristics to abandon the gnfs search early or not (i.e. if early gnfs E is way above snfs E, then definitely carry on along the gnfs track; if it is way below, then abandon early; and if it is, say, 2 times lower, then expect gnfs E to overcome snfs E - here, you will need some heuristic from experimentation)

Should this option ever be persued, I am more than willing to help run test cases if you need data to feed the effort.

Or is the well established criteria cited by Batalov good enough?

[Mr. Odd]

With the merge with msieve, can we get GPU/CUDA horsepower added to YAFU?

[Dubslow]

Originally Posted by swellman

Just want to capture this suggestion for future consideration.



Should this option ever be persued, I am more than willing to help run test cases if you need data to feed the effort.

Or is the well established criteria cited by Batalov good enough?

That criteria listed by Batalov is already in use (the post I used for reference was http://www.mersenneforum.org/showpos...01&postcount=2, which you can find in the comments of nfs.c). As for comparing Murphy E scores, that would take rather more work; if it's done, it won't be done until the next version.

Originally Posted by Mr. Odd

With the merge with msieve, can we get GPU/CUDA horsepower added to YAFU?

You might be able to get it now if you merely link yafu against a CUDA-enabled Msieve. (You'd need two binaries -- one with CUDA, one without. Currently, CUDA is a compile-time option only for Msieve.)

[VBCurtis]

Any chance of a precompiled binary with the change implemented to take advantage of the hot new 64-bit asm windows sievers? I do not have a windows compiler installed.
-Curtis

[lorgix]

Originally Posted by jasonp

That table dates back to the beginning of the NFS code in 2007. While a single computer can now handle a C154, back then handling a C154 at all was a pipe dream. The current code has no clue how to account for parallel runs that will reduce the wallclock time. Is it really more helpful to do a poly search for GNFS200 and say something like 'commencing polynomial selection, deadline 10 CPU years' ?

Originally Posted by bsquared

YAFU was not originally intended for jobs larger than ~c155. Even with today's hardware, much beyond that and you're going to need a cluster to get the job done in a reasonable time frame.

The table no doubt needs an overhaul, but I'd need help with it, and I can't see a need for it to go much higher than somewhere in the c160's.

So I shouldn't be using YAFU for factoring numbers much bigger than 160 digits?
What should I be using instead?
Will YAFU+msieve ever be suited for factoring say a c185?

[henryzz]

Originally Posted by lorgix

So I shouldn't be using YAFU for factoring numbers much bigger than 160 digits?
What should I be using instead?
Will YAFU+msieve ever be suited for factoring say a c185?

When doing a c185 takes similar time to doing a c160 now I imagine they will be able to. For now it just needs a bit more manual intervention.

[bsquared]

Originally Posted by lorgix

So I shouldn't be using YAFU for factoring numbers much bigger than 160 digits?
What should I be using instead?
Will YAFU+msieve ever be suited for factoring say a c185?

It will work and you can use it, but it becomes increasingly less optimal¹ to do so as the numbers go north of 160 digits. This is because you need to put more and more thought into the process to get the best results. For example testing the polynomials via trial sieving, knowing when to stop searching vs. going for a better poly, knowing when to start test building matrices, and using the matrix building options within msieve to their potential, just off the top of my head. These are things I've taken steps toward automating, but I'm not there yet and in any case automation will probably never be as good as an experienced human.

¹ As Xilman likes to point out, optimal with respect to what cost function? If you cost function is minimizing human interaction, then maybe YAFU is the right approach even for huge numbers. But it will be decidedly less optimal with respect to a power/calendar time cost function.

[EdH]

Would it be possible to add a check, during sieving breaks, for an intermediate file of externally generated relations, and if found, add those to the main relations file?

This would be similar to the spairs.add file being brought into the factmsieve.py and factMseive.pl scripts. Perhaps a fixed filename, i.e. "exrels.add" could be used.

Thanks for all.