Thanks for the responses. Seems like a bit of luck and/or magic is required to find the "best" poly (barring extensive GPU searching).

I will try the wide option with -psearch on my next composite. Also might try shifting the block option. Good stuff.

[QUOTE=jasonp;337512]There was a lot of uncertainty for large problems whether to expect better polynomials when starting from the smaller leading coefficients; Kleinjung's algorithm makes it feasible to find polynomials no matter how small the leading coeff is. However, now that we have GPU poly selection and can search ranges extremely thoroughly, the conclusion is that the polynomials that get found with extremely small leading coefficients (i.e. around 1) are not systematically better than polynomials whose high coeff is larger; and there are many many fewer of the former, so fewer chances for luck to turn up something good.

The problem is that the code has not been updated to reflect that, and will always start at 1.[/QUOTE]
How do you perform GPU poly selection? I suspect it's not fire&forget like YAFU+msieve...

Can we improve poly selection parameters by running wider and/or deeper searches and taking note of where the best poly is found? I wouldn't mind spending some time on that if it's deemed worthwhile. I have a bunch of p^q-1 cofactor >150 digit gnfs candidates anyway.

The code has to be built for GPU poly selection, i.e. with CUDA=1, and you need the CUDA tools and a pthreads library (and also a little patience, the exact location of CUDA files seems to be quite CUDA-version-and-OS-specific).

The GPU branch is also natively multithreaded so it would not be productive to use YAFU's multithreading framework, though it doesn't matter so much with 150-digit problems. Jobs that size already keep a single GPU mostly busy with one thread.

Otherwise the interface to a compiled Msieve binary is the same. See the latest Readme.nfs for details.

[QUOTE=jasonp;337595]The code has to be built for GPU poly selection, i.e. with CUDA=1, and you need the CUDA tools and a pthreads library (and also a little patience, the exact location of CUDA files seems to be quite CUDA-version-and-OS-specific).

The GPU branch is also natively multithreaded so it would not be productive to use YAFU's multithreading framework, though it doesn't matter so much with 150-digit problems. Jobs that size already keep a single GPU mostly busy with one thread.

Otherwise the interface to a compiled Msieve binary is the same. See the latest Readme.nfs for details.[/QUOTE]
Thanks for the info.

Seems like there is some downside to using a GPU for poly selection, although I don't really understand what it is.

Could a GPU & CPU be used for poly selection at the same time without considerable overlap/inefficiency?

There's no downside; the GPU code runs about 100x faster than CPU code assuming that the GPU is about as 'nice' as the machine it's plugged into. Doing CPU polynomial selection at the same time is a waste of effort, better to just make the CPU perform stage 2 on multiple threads, or something.

What happened here? Hardware error?

Latest Msieve and YAFU
 

There appears to have been some recent [url=http://www.mersenneforum.org/showthread.php?t=17401&page=10]big performance improvements in Msieve 1.51[/url] (which is up to SVN 929 or so). Word on the street says LA is now faster/better/stronger than ever.

Does YAFU take advantage of this if one just upgrades Msieve on their machine, or does YAFU need to be recompiled? Or is this something for YAFU 1.35?

Thanks for any insights.

I believe yafu still uses the postprocessing code from 1.38. That is only for the quadratic sieve though. For nfs it uses an external msieve binary.
For the quadratic sieve the matrix is small enough that there won't be that much of a time saving. I suppose it would be nice to upgrade at some point for completeness' sake.

Henryzz's right as far as QS goes... I don't think the LA changes in msieve will impact QS at all. NFS in yafu uses library calls to msieve, so it's not as simple as pointing to a new external binary. You'd need to build the new msieve and then re-build yafu. As long as the library interface hasn't changed, this should work.

[QUOTE=bsquared;348266]Henryzz's right as far as QS goes... I don't think the LA changes in msieve will impact QS at all. NFS in yafu uses library calls to msieve, so it's not as simple as pointing to a new external binary. You'd need to build the new msieve and then re-build yafu. As long as the library interface hasn't changed, this should work.[/QUOTE]

Thanks B^2 (and you too Henryzz). Unfortunately I can't compile in Windows, so no love. I might try on one of my Linux64 boxes.

This issue aside, any thoughts on Yafu 1.35? I've been using 1.34 with great results, just curious if you're toying with any new features.

[QUOTE=swellman;348388]Thanks B^2 (and you too Henryzz). Unfortunately I can't compile in Windows, so no love. I might try on one of my Linux64 boxes.

This issue aside, any thoughts on Yafu 1.35? I've been using 1.34 with great results, just curious if you're toying with any new features.[/QUOTE]

I've barely touched the code in months, but just yesterday I started updating the todo list. That's always the first step - make a list.

I'd like to have AVX2 code in an eventual 1.35, maybe gnfs trial sieving, some work on the multithreading in nfs sieving, and the usual bugfixes and minor tweaks. WraithX continues his APRCL development, and at some point I expect he'll update the copy in yafu. Maybe I could even convince danaj to put his ecpp into yafu :innocent: (although likely that's a fairly major endeavor). Not promising any of this stuff... just a sneak peak into what I'm thinking.