mfaktc: a CUDA program for Mersenne prefactoring

[Bdot]

Originally Posted by Christenson

This is perfectly good practice, but when I have 30 or 40 hours work involved, I don't like nonzero chances where I don't have to take them!

I played around with the current code on Windows. Stopped the process in a debugger in interesting places (e.g. between writing the checkpoint and closing the file), and then killed the process.

As the write is atomic (a single line shorter than a disk block), I either had the file content of before the write, or the new contents. No corruption. (I know this is no proof, just a test aimed at breaking it.)

Therefore I think that no special signal handling is necessary - as a precaution one or two backup copies of the checkpoint file are sufficient.

prime95 may be a different story as the save files there can be much bigger, so that writes to the file are not atomic. And there I already saw a few times that the latest save file was not usable.

B.

[Christenson]

Originally Posted by jasonp

Win32 has a limited range of signals you can install a handler for; even then, the handler runs once only. Hitting Ctrl-C will run your SIGINT handler; hitting it again will kill your program, without running the handler.

Fine for purposes of mfaktc, but what about those Windows programs that simply won't be shut down, especially as you TRY to shut down the system nicely?

[chalsall]

Originally Posted by Christenson

Fine for purposes of mfaktc, but what about those Windows programs that simply won't be shut down, especially as you TRY to shut down the system nicely?

Oh, you mean the virus', worms and other malware?

Originally Posted by Christenson

The inability to stop a program in an operating system indicates a problem with the operating system.

You said it, not me....

[TheJudger]

Hi Jason,

Originally Posted by jasonp

Win32 has a limited range of signals you can install a handler for; even then, the handler runs once only. Hitting Ctrl-C will run your SIGINT handler; hitting it again will kill your program, without running the handler.

Is this specific to Win32? On my Windows 7 64bit box I can run it multiple times. The difference to Linux is that you have to register your signal handler again (BSD style).

e.g.

void my_signal_handler(int signum)
/* very simple signal handler */
{
#ifdef WINDOWS
  signal(signum, &my_signal_handler);
#endif
  ...
}

int main()
{
  signal(SIGINT, &my_signal_handler);
  ...
}

Of course this is not perfect...

Oliver

[Christenson]

Oliver:
Let's do a simple sample program, "sigtest", that sleeps and says either "don't touch me, I'm sleeping!" or "It's OK, I'm awake" on Ctrl-C, and then says "exiting" on the second Ctrl-C. All printing is from the main loop. I can test Linux64 and Win32.

E.

[diamonddave]

I've been playing on my new computer with mfakt for a week or 2, right now I'm at 311 candidates tested. Most of them from 69 to 70 bit, and a small batch from 68 to 69 bit. And I haven't found 1 factor yet, where on average I should have found something along 4 or 5.

I'm starting to think there might be some problem with my hardware: i5-2500k not overclocked with a GTX 560, only running one instance of mfakt.

I'm testing exponent in the 54-55XXXXXX range, does anyone have a candidate in that range with a 69 bit factor, it would help me have better confidence in my hardware.

Or maybe someone already tested to that bit-level in that range while only submitting factor found?

Thanks in advance,

[diep]

Originally Posted by diamonddave

I've been playing on my new computer with mfakt for a week or 2, right now I'm at 311 candidates tested. Most of them from 69 to 70 bit, and a small batch from 68 to 69 bit. And I haven't found 1 factor yet, where on average I should have found something along 4 or 5.

I'm starting to think there might be some problem with my hardware: i5-2500k not overclocked with a GTX 560, only running one instance of mfakt.

I'm testing exponent in the 54-55XXXXXX range, does anyone have a candidate in that range with a 69 bit factor, it would help me have better confidence in my hardware.

Or maybe someone already tested to that bit-level in that range while only submitting factor found?

Thanks in advance,

Could you post the candidate list you tried?

Thanks,
Vincent

[diamonddave]

Originally Posted by diep

Could you post the candidate list you tried?

Sure thing

[TheJudger]

Originally Posted by diamonddave

I've been playing on my new computer with mfakt for a week or 2, right now I'm at 311 candidates tested. Most of them from 69 to 70 bit, and a small batch from 68 to 69 bit. And I haven't found 1 factor yet, where on average I should have found something along 4 or 5.

I'm starting to think there might be some problem with my hardware: i5-2500k not overclocked with a GTX 560, only running one instance of mfakt.

I'm testing exponent in the 54-55XXXXXX range, does anyone have a candidate in that range with a 69 bit factor, it would help me have better confidence in my hardware.

First of all you could run the full selftest (mfaktc.exe -st).

M54789601 has one known factor between 2⁶⁷ and 2⁶⁸
M54790157 has one known factor between 2⁶⁹ and 2⁷⁰
hint: http://mersenne.org/report_exponent/

Oliver

[Christenson]

It's worth noting that the ranges we are now getting for TF from primenet are now beyond optimal for CPU-only TF, so we can expect the AVERAGE GHz-days effort per factor found to match or exceed that of 2 LL tests, or about O(200) GHz days for exponents in the 50M range.

[Xyzzy]

This morning we discovered that two of our eight workers had transferred all of their remaining worktodo.txt contents to their results.txt files and thus were idle.