mersenneforum.org > YAFU yafu bugs
 Register FAQ Search Today's Posts Mark Forums Read

2012-05-04, 03:20   #34
Dubslow

"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

1C3516 Posts

Quote:
 Originally Posted by LaurV Delete it! Fast! Mr Silverman will be all on your head when he wakes up! P.S.: ideals.
Hey, I never said it wasn't a stupid question. I think it'll have to wait until after finals when I can go through that NFS paper in more depth.

 2012-05-11, 23:40 #35 Dubslow Basketry That Evening!     "Bunslow the Bold" Jun 2011 40
2012-05-12, 00:40   #36
bsquared

"Ben"
Feb 2007

22·23·37 Posts

Quote:
 Originally Posted by Dubslow Code: starting SIQS on c90: 529418472105108303888654672419843173237325298224814103927451866230400511694248308961680453 ==== sieve params ==== n = 91 digits, 302 bits Umm... what? Minor bug to be sure, but... kinda funny looking. (Line 3394, FDB reports it as C90. The first and last digits match.) (Edit: BTW, it says SSE2 all over the place; is that a function of the compiler, or...? How hard would it be to get AVX?)
The first one reports the size of the input, the second reports the size after the multiplier has been applied (we really factor k*N, for some small k that optimizes properties of the factor base).

The SSE2 business is a function of the fact that I hand-wrote a lot of code utilizing SSE2 registers . I would have to re-write all of those things in order to utilize AVX, and so far I haven't seen a clear benefit to that cost.

2012-05-12, 00:43   #37
Dubslow

"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

11100001101012 Posts

Quote:
 Originally Posted by bsquared The first one reports the size of the input, the second reports the size after the multiplier has been applied (we really factor k*N, for some small k that optimizes properties of the factor base). The SSE2 business is a function of the fact that I hand-wrote a lot of code utilizing SSE2 registers . I would have to re-write all of those things in order to utilize AVX, and so far I haven't seen a clear benefit to that cost.
It's never a bug, is it? Me and YAFU... always PEBKAC.

Attachment 7965

2012-05-12, 01:09   #38
bsquared

"Ben"
Feb 2007

22×23×37 Posts

Quote:
 Originally Posted by Dubslow It's never a bug, is it? Me and YAFU... always PEBKAC. Attachment 7965
I wouldn't feel bad if you blamed it on poor documentation.

2012-05-12, 01:20   #39
Dubslow

"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

722110 Posts

Quote:
 Originally Posted by bsquared I wouldn't feel bad if you blamed it on poor documentation.
I wouldn't feel bad about doing such if I actually contributed anything to YAFU besides post count

 2012-05-13, 04:38 #40 WraithX     Mar 2006 11·43 Posts Hello bsquared, I think I may have run into a problem. I'm doing nfs on a number, and sometimes one of the sievers will crash, and then yafu says it has "Received signal 3". Then when all sievers have finished their range, yafu terminates. Is it possible to have it continue sieving even if one of the sievers had crashed during that last range? Here is a copy of what I'm seeing: Code: found 22916812 relations, need at least 44869961, continuing with sieving ... nfs: commencing algebraic side lattice sieving over range: 31243191 - 31323191 nfs: commencing algebraic side lattice sieving over range: 31163191 - 31243191 nfs: commencing algebraic side lattice sieving over range: 31083191 - 31163191 nfs: commencing algebraic side lattice sieving over range: 31483191 - 31563191 nfs: commencing algebraic side lattice sieving over range: 31803191 - 31883191 nfs: commencing algebraic side lattice sieving over range: 30843191 - 30923191 nfs: commencing algebraic side lattice sieving over range: 31323191 - 31403191 nfs: commencing algebraic side lattice sieving over range: 31643191 - 31723191 nfs: commencing algebraic side lattice sieving over range: 31403191 - 31483191 nfs: commencing algebraic side lattice sieving over range: 30763191 - 30843191 nfs: commencing algebraic side lattice sieving over range: 31563191 - 31643191 nfs: commencing algebraic side lattice sieving over range: 30683191 - 30763191 nfs: commencing algebraic side lattice sieving over range: 30923191 - 31003191 nfs: commencing algebraic side lattice sieving over range: 31723191 - 31803191 nfs: commencing algebraic side lattice sieving over range: 31003191 - 31083191♪◙ Warning: lowering FB_bound to 31643190. Warning: lowering FB_bound to 31403190. Warning: lowering FB_bound to 31803190. Warning: lowering FB_bound to 31163190. Warning: lowering FB_bound to 30683190. Warning: lowering FB_bound to 31243190. Warning: lowering FB_bound to 31083190. Warning: lowering FB_bound to 31723190. Warning: lowering FB_bound to 30843190. Warning: lowering FB_bound to 31323190. Warning: lowering FB_bound to 31483190. Warning: lowering FB_bound to 31003190. Warning: lowering FB_bound to 31563190. Warning: lowering FB_bound to 30923190. Warning: lowering FB_bound to 30603190. Warning: lowering FB_bound to 30763190. Special q 31643191 does not divide Received signal 3... please wait SCHED_PATHOLOGY q0=30952183 k=3025 excess=4 SCHED_PATHOLOGY q0=31466119 k=414 excess=4 total yield: 225921, q=31003199 (0.19416 sec/rel) total yield: 227093, q=31323203 (0.19403 sec/rel) total yield: 229532, q=31883191 (0.19248 sec/rel) total yield: 227840, q=31483213 (0.19488 sec/rel) total yield: 230264, q=30763207 (0.19326 sec/rel) total yield: 232742, q=31563193 (0.19267 sec/rel) total yield: 231013, q=31083193 (0.19469 sec/rel) total yield: 231129, q=31643191 (0.19484 sec/rel) total yield: 235153, q=31803197 (0.19413 sec/rel) total yield: 236249, q=31403249 (0.19330 sec/rel) total yield: 235944, q=31243193 (0.19397 sec/rel) total yield: 237541, q=31163191 (0.19342 sec/rel) total yield: 237676, q=30683203 (0.19404 sec/rel) total yield: 238889, q=30843199 (0.19396 sec/rel) total yield: 239558, q=30923197 (0.19439 sec/rel) Right where it says "Special q 31643191 does not divide" is when the siever crashes. Please let me know if you need any more information. Thanks for your time. Also, here is the command line I am using to start this job: Code: yafu-32k-x64 "nfs(num)" -R -v -threads 16 -job c159.job -o nfs.dat
2012-05-14, 16:08   #41
bsquared

"Ben"
Feb 2007

22·23·37 Posts

Quote:
 Originally Posted by WraithX Hello bsquared, I think I may have run into a problem. I'm doing nfs on a number, and sometimes one of the sievers will crash, and then yafu says it has "Received signal 3". Then when all sievers have finished their range, yafu terminates. Is it possible to have it continue sieving even if one of the sievers had crashed during that last range? Here is a copy of what I'm seeing: Right where it says "Special q 31643191 does not divide" is when the siever crashes. Please let me know if you need any more information. Thanks for your time. Also, here is the command line I am using to start this job: Code: yafu-32k-x64 "nfs(num)" -R -v -threads 16 -job c159.job -o nfs.dat
Let me first explain what's happening. yafu uses system calls to execute the external ggnfs binaries when doing the lattice sieving portion of NFS. In order to support graceful ^c during sieving (i.e., finish sieving range, merge thread data into main data, clean up, and exit), I watch for abnormal exit conditions from the system command, since it is "system" that gets the ^c instead of yafu. Since I don't know all of the possible exit conditions from the ggnfs binary, any non-zero exit condition is interpreted as ^c. Thus a siever crash gets interpreted as a user interrupt.

I see two things that can be done 1) I can ignore the exit condition of the ggnfs binary, which will solve your issue but will make it impossible (or at least much more difficult) to gracefully interrupt an ongoing factorization, or 2) attempt to learn all of the exit conditions of ggnfs on all supported OSes and build in the smarts to deal with various exit conditions. 1) does not sound very appealing and I don't have the time/willpower to do 2). I'm open to other suggestions.

edit:
What does factMsieve.pl/py do in this situation?

edit2:
maybe there is a way to issue the system calls in a non-blocking way so that yafu can retain visibility of an interrupt without relying on the exit condition of ggnfs...

Last fiddled with by bsquared on 2012-05-14 at 16:22

2012-05-15, 02:50   #42
WraithX

Mar 2006

1110110012 Posts

Quote:
 Originally Posted by bsquared I'm open to other suggestions. edit: What does factMsieve.pl/py do in this situation? edit2: maybe there is a way to issue the system calls in a non-blocking way so that yafu can retain visibility of an interrupt without relying on the exit condition of ggnfs...
My first thought was that maybe you could just find out what the ^C exit code is and terminate after that. But I'm sure that could vary from system to system.

It looks like factmsieve.py usually expects a zero return value, but it also has a special case for the crash of the siever, like so:
Code:
    if ret and ret != -1073741819:
output('-> Return value {0:d}. Updating job file and terminating...'
So, maybe you could consider zero or -1073741819 a "success" and proceed with sieving. Any other error code you can consider a termination condition.

Also, while looking around for nonblocking system calls for Windows, about the only suggestion I could find was to try:
Code:
system("start mycommand");
It looks like system() calls, in Windows, are just sent to the windows command line interpreter, so the "start" command line option will start the siever and return right away. I'm not sure what the return value of "start" is. Hopefully you will be able to monitor the status of the siever process to know if it returned 0, -1073741819, or maybe something else. You can run "start /?" at the command prompt if you want some more information about it. I've just tried to run several programs from "start", but the return code was always zero. So this might not be a good way forward.

2012-05-15, 04:42   #43
bsquared

"Ben"
Feb 2007

22×23×37 Posts

Quote:
 Originally Posted by WraithX So, maybe you could consider zero or -1073741819 a "success" and proceed with sieving. Any other error code you can consider a termination condition.
I can try that, sure. And as more cases are seen they can be added to the source.

2012-05-16, 03:37   #44
WraithX

Mar 2006

11×43 Posts

Quote:
 Originally Posted by bsquared I can try that, sure. And as more cases are seen they can be added to the source.
Actually, thinking about it, it looks like yafu received a signal 3, and not the -1073741819 that was returned from the crashing siever. I wonder what the return codes are for the system() command. I tried searching once, but didn't have much luck. Hopefully, 3 is the special code for "Program Crashed!". But I worry that it may represent a more generic "Error or quit signal received". If you want to test it, you can just run a small range and kill one of the sievers in Task Manager.

Luckily I haven't had a siever crash on me in a long time, so I'm almost done factoring the C159.

 Similar Threads Thread Thread Starter Forum Replies Last Post EdH YAFU 8 2018-03-14 17:22 Matt Software 1 2007-02-20 19:13 JuanTutors Software 9 2006-09-24 21:22 TTn 15k Search 2 2004-11-24 22:11 TTn 15k Search 16 2004-06-16 01:22

All times are UTC. The time now is 03:00.

Sat Apr 17 03:00:55 UTC 2021 up 8 days, 21:41, 0 users, load averages: 2.35, 2.26, 2.23