[QUOTE=Andi47;264134]Just started yafu "nfs(<c121>)" -v -threads 6, but it seems that it hasn't taken the "-threads 6" flag: the output looks like the msieve output for one thread, only one of 8 threads of my i7 is busy (CPU load ~12%), and the msieve.log which it created says that the time limit for poly search is somewhat more than 4 hours (which seems normal for a c121). (BTW: my yafu.ini contains the line "threads=6", this seems to be ignored too with yafu "nfs()".)


(BTW2: I have killed the job after 2 minutes and switched back to aliqueit which now uses factmsieve.pl to factor the c121)[/QUOTE]

Some ranges take longer to search than others, and the current code waits until all ranges are done before starting each thread on a new range. This means that occasionally only 1 thread will be running. Did you look at the history in the task manager to see if it had used 6 threads at any point during the run? Specifying the number of threads to use has always worked fine, to my knowledge, so I strongly suspect you just happened to look at it when the last thread was finishing it's range. It is on my todo list to make poly selection use the more efficient thread pool structure that my SIQS code uses - which will make the issue you observed go away.

[QUOTE=bsquared;264198]Some ranges take longer to search than others, and the current code waits until all ranges are done before starting each thread on a new range. This means that occasionally only 1 thread will be running. Did you look at the history in the task manager to see if it had used 6 threads at any point during the run? Specifying the number of threads to use has always worked fine, to my knowledge, so I strongly suspect you just happened to look at it when the last thread was finishing it's range. It is on my todo list to make poly selection use the more efficient thread pool structure that my SIQS code uses - which will make the issue you observed go away.[/QUOTE]

No, I didn't take a look at the history in the task manager (is there any in windows when I just opened the task manager?). My PC is currently occupied with another factorization, I will take another look next weekend.

Edit: do all threads write to the same msieve.dat.p outputfile?

[QUOTE=Andi47;264200]Edit: do all threads write to the same msieve.dat.p outputfile?[/QUOTE]

No, each thread writes to a separate file - by default they are named nfs.dat.<thread-num>.p. The files are then combined into nfs.dat.p at the end of every range.

BTW, here is a graphic of my processor utilization on a 6 thread run during poly selection. You can see the cyclical utilization behavior - it uses all 6 threads for a while, then ramps down as threads finish their range. When all ranges are done, it ramps back up, etc...

Running NFS on the C103 from (10^132+57)/446393613148636496363324431219, Yafu goes through the full process only to tell me:

"too few cycles, matrix probably cannot build"

What next?

You probably are right on the edge of having enough relations, so that filtering could start but could not finish successfully. Try sieving a little bit more.

How can I do that? When I run YAFU -R and call NFS it tries to sieve right away.

[QUOTE=Mr. Odd;264326]How can I do that? When I run YAFU -R and call NFS it tries to sieve right away.[/QUOTE]

When you restart, you should see something printed to the effect of:
[CODE]
nfs: found 65752 relations, continuing job at specialq = 542557
[/CODE]

Using the specialq from this line as a starting point, use the following command to force some extra sieving:
[CODE]
YAFU "nfs(<your number here>)" -R -ns 542557,547557[/CODE]
With the stop value something like 5000 more than the start.

After this finishes, restart as before. Repeat as long as the filtering fails.

p.s.
It might not be a bad idea to back up your .dat file and .job file first, in case something goes wrong.

version 1.27 now available
 

[QUOTE=Mr. Odd;264326]How can I do that? When I run YAFU -R and call NFS it tries to sieve right away.[/QUOTE]

Or... you can download version 1.27 and just do -R. I modified my local msieve source (which is built into YAFU) to pass an error code back up the chain when encountering the "too few cycles, matrix probably cannot build" condition instead of just aborting. So yafu should now detect this and automatically continue sieving.

Other changes include:

[FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2]+ tweaks to siqs parameter selection for numbers > 80 digits - resulting in fairly significant improvements at 90+ digits (~10% on a c95, ~20% on a c100)

[FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2]+ modified NFS poly selection to use more efficient thread pool architecture
[/SIZE][/FONT][/SIZE][/FONT][/SIZE][/FONT][/SIZE][/FONT]
This last change means that cpu utilization during multi-threaded poly selection should now be pegged at whatever % of your cpu you specify - no more waiting for a new batch to start when threads finish.

On my windows x64 system, the siqs parameter tweaks pushed the NFS crossover up by a little over a digit.

Good, the thread pool change really speeds polyselect step! Yafu's SourceForge page is being silly - it selected readme as default download file. Should be the archive with the binaries, yes ?

[QUOTE=Karl M Johnson;264349]Yafu's SourceForge page is being silly - it selected readme as default download file. Should be the archive with the binaries, yes ?[/QUOTE]

Yes, thanks! Should be fixed now.

[QUOTE=bsquared;264342]Or... you can download version 1.27 and just do -R. I modified my local msieve source (which is built into YAFU) to pass an error code back up the chain when encountering the "too few cycles, matrix probably cannot build" condition instead of just aborting. So yafu should now detect this and automatically continue sieving.
[/QUOTE]

That did the trick! Thanks for this, much better than your original suggestion. :-)