Aliqueit.exe discussion

[mklasson]

Originally Posted by Joshua2

Looks like its still not fixed. $SYS_BIN_PATH="c:/cygwin/bin"; is what I have. I did $GGNFS_BIN_PATH="C:\\\Program Files\\\ggnfs"; and it seemed to work, was having errors before on that one. Should I switch to the 3 backslash?
Edit: also, each time I restart I lose all the sieving I've done, its getting annoying...

I'm surprised 3 backslashes works. You can replace them with one forward slash.

$GGNFS_BIN_PATH="c:/PROGRA~2/ggnfs/bin";

is what I use. You can probably get away with something similar. I can't remember if the script had problem with spaces in filenames or if I just wanted to be sure it wouldn't be a problem...

Originally Posted by Joshua2

Canceled it, and it looks like it deletes everything, along w/ another cat error. Is it supposed to save automatically and resume?

Aliqueit will only delete stuff if it finds a factor in the log.

[Joshua2]

Ok, I basically tried that except since same if and else just deleted that and it seems to have worked. I'll keep you posted.
Edit: Got the three backslash from programming c#. That's the way you do it since / says ignore next character, so you do the first and it ignores the second and then you need the third or something weird like that.

[10metreh]

Originally Posted by Joshua2

Ok, I basically tried that except since same if and else just deleted that and it seems to have worked. I'll keep you posted.
Edit: Got the three backslash from programming c#. That's the way you do it since / says ignore next character, so you do the first and it ignores the second and then you need the third or something weird like that.

Is that with my update to the script?

Edit: just saw what the post said. That's almost exactly what I did in my update.

[Joshua2]

Yes, thanks! I got a new error here, but I'm not sure its bad. Its from msieve doing the final linear algebra. It went past that and says it will complete in 2 min w/ 4 threads. But I did notice that while it was sieving it kept on trying to reduce matrix, and kept on saying it needed more relations, is that normal? It seems it would be more efficient to go until you probably have enough, it must have tried 10 times, and the number didn't go down much that it needed each time.

[mklasson]

Originally Posted by Joshua2

Yes, thanks! I got a new error here, but I'm not sure its bad. Its from msieve doing the final linear algebra. It went past that and says it will complete in 2 min w/ 4 threads. But I did notice that while it was sieving it kept on trying to reduce matrix, and kept on saying it needed more relations, is that normal? It seems it would be more efficient to go until you probably have enough, it must have tried 10 times, and the number didn't go down much that it needed each time.

Those errors look pretty harmless.

Yes, that's normal. It will go back and forth between sieving and relation processing quite a number of times. Just give it some (or lots depending on the size of your composite...) time.

[Joshua2]

It worked. Now I'm testing gnfs vs. yafu on a c98. I already did it in the line of duty w/ yafu and it took 4.14 hours. I'm trying it w/ gnfs, and aliquot (modified ini to c98 min instead of 99) used poly5 from gnfs suite instead of msieve to pick poly. Do you know why this might be?

[Joshua2]

Even though it didn't use msieve it took 3 hours instead of a little over 4, so it was 25% faster. Might consider C98 min for nfs.

[mdettweiler]

Originally Posted by Joshua2

Even though it didn't use msieve it took 3 hours instead of a little over 4, so it was 25% faster. Might consider C98 min for nfs.

Based on my personal experience (and others' that I've read about, too) the crossover point with the current array of applications is around 96 digits. I personally do anything 95 digits or less with QS, and 96 digits or more with GNFS.

Note: msieve has a built-in limit of >97 digits (i.e. must be 98 digits or greater) for NFS sieving and polynomial selection. Thus, any 96 or 97 digit GNFSes must have their polynomial selection performed with GGNFS, and also you must set $DOCLASSICAL to 0 in factMsieve.pl (near the end of the top section where all the user-configurable options are stored) so that it doesn't try to use msieve for the small amount of line sieving it normally does at the beginning of the job (because otherwise msieve will ignore factMsieve.pl's instructions and run QS on the number anyway, which of course is not what factMsieve.pl is expecting in its output and thus it could probably mess things up a lot).

[Joshua2]

So I don't know why aliq didn't use msieve on c98, but when I did it manual and stack in the msieve.fb, and deleted all the other files, and killed and restarted, it used it, and it got a better poly, so it should be even better than 25%. Any ideas, it would be nice automated.

[Joshua2]

C98 took just over 2 hours using msieve to poly select. Its funny it used msieve auto w/ my C108, but not the C98. If I were you I would make aliquot use 96 as the crossover, and if its a 96 or 97 use the other pearl script that doesn't use msieve. That should speed things up right?
Edit: Think I need to put "" in like msieve_cmd = "C:\Program Files\ggnfs\msieve" - that seems to have fixed it... thats weird

[Joshua2]

Change in 1.40 msieve
- Modified the main driver to allow NFS on any size input, no matter
how small, if only the postprocessing is desired
So do you think aliq 1.07 might be smart enough to be able to set use msieve for poly to false under c98, and true over? And msieve can still do the post-proc. I would like to test the breakeven point on my box.