Is there any way to disable the screen output of the polyfind step? Initially it was pretty awesome to watch the torrent of output when running 12 threads in parallel, but eventually the novelty wore off and I realized that half a thread is being spent just running the xterm and writing to disk. It's coming from inside libmsieve, though, so I don't know if there's any easy way to turn it off.

BTW, Ben, fantastic work on the recent versions. My aliquot workers took about 5 weeks to go through all the c104's in open sequences, using mostly SIQS and some GNFS at the end. With the addition of the minimum relations check, the multi-threaded polyfind, and the recent SIQS improvements, they are now about 60% through the c105's in just over a week. Without actually measuring anything, it feels like 2-3x improvement in throughput. Great stuff.

[QUOTE=bchaffin;265185] Is there any way to disable the screen output of the polyfind step? Initially it was pretty awesome to watch the torrent of output when running 12 threads in parallel, but eventually the novelty wore off and I realized that half a thread is being spent just running the xterm and writing to disk. It's coming from inside libmsieve, though, so I don't know if there's any easy way to turn it off.
[/QUOTE]

I've wondered that myself - I'm guessing that eventually jrk/jason will disable all of the output. Presumably when the (still relatively new) uber fast poly select code gains enough maturity. Maybe if one of them is reading this thread they could comment.

[QUOTE=bchaffin;265185]

BTW, Ben, fantastic work on the recent versions. My aliquot workers took about 5 weeks to go through all the c104's in open sequences, using mostly SIQS and some GNFS at the end. With the addition of the minimum relations check, the multi-threaded polyfind, and the recent SIQS improvements, they are now about 60% through the c105's in just over a week. Without actually measuring anything, it feels like 2-3x improvement in throughput. Great stuff.[/QUOTE]

:smile::smile::smile:

The debug output always happens; you can redirect to /dev/null if it's really bothersome :)

Honestly the current code is not well suited for very high-throughput use, and making it work better on RSA768-size numbers is taking up all my time.

Talking of screen output, I'm using YAFU in Windows and redirecting output to a file. I'd like to see a switch that replaces the multiple backspaces (that appear in the output to enable the next line to overwrite the previous one on the screen) with a single newline. Is that possible, please?

Jane

[QUOTE=jasonp;265193]The debug output always happens; you can redirect to /dev/null if it's really bothersome :)[/QUOTE]
"> NUL" for windows users.

[QUOTE=Karl M Johnson;265301]"> NUL" for windows users.[/QUOTE]
I don't want to throw the output away, as I parse the redirected output file to obtain the factors; this seems easier than trying to get them from factor.txt. I also like to browse the output file to give me an idea how a factorization is proceeding.

The factor log has a regular format that I think would be just as easy to parse as redirected output. What parsing language are you using?

[QUOTE=bsquared;265358]The factor log has a regular format that I think would be just as easy to parse as redirected output. What parsing language are you using?[/QUOTE]
APL

Actually, I've just done what I should have done ages ago: read the help text!

It seems the -of flag is exactly what I need, returning the parenthesized input and the factors separated by slashes, which is much easier to parse than the debug output.

As I mentioned earlier, the debug output is handy for seeing how yafu is getting on.

[QUOTE=BudgieJane;265390]Actually, I've just done what I should have done ages ago: read the help text!

It seems the -of flag is exactly what I need, returning the parenthesized input and the factors separated by slashes, which is much easier to parse than the debug output.

As I mentioned earlier, the debug output is handy for seeing how yafu is getting on.[/QUOTE]

Ok, great. You have WraithX to thank for that - he implemented that and a few other switches a while back.

It's probably not a major issue, but what causes this?
[code]elapsed time of 378.0667 seconds exceeds 409 second deadline; poly select done[/code]