Prime95 version 27.7 / 27.9

[debrouxl]

Well, mistakes resulting from inattention or whatever else do happen, to all of us

+1 for henryzz's suggestion of indicating that the 32-bit address space is the problem.

[diamonddave]

Originally Posted by debrouxl

Well, mistakes resulting from inattention or whatever else do happen, to all of us

+1 for henryzz's suggestion of indicating that the 32-bit address space is the problem.

I would suggest naming the zip file differently (I was caught also) I couldn't figure out why I kept getting memory error in result.txt

P95v277.win64.zip
P95v277.win32.zip

[LaurV]

Originally Posted by diamonddave

I would suggest naming the zip file differently (I was caught also) I couldn't figure out why I kept getting memory error in result.txt

P95v277.win64.zip
P95v277.win32.zip

Luckily I was ok with the old style (p95.zip and p64.zip) and never installed the wrong version before checking it, but despite of it, I would give a +1 for diamonddave's suggestion. Shit could happen to anyone (including me!).

[Dubslow]

What I would like for MPrime is the ability to pause individual workers without having to stop MPrime and change WorkerThreads= each time. To that end, here's the best idea I (meaning msft) have had how to do that:

CUDALucas has this nice -k option, where you can change the status of other options on the fly by pressing a letter that corresponds to the option.

∰∂ CUDALucas -c 10000 -f 1474560 -polite 64 -k worktodo.txt

continuing work from a partial result M25786547 fft length = 1474560 iteration = 12136257
p   -polite 0
p   -polite 64
p   -polite 0
p   -polite 64
Iteration 12140000 M( 25786547 )C, 0xa04ade062b1d3458, n = 1474560, CUDALucas v2.00a err = 0.06268 (0:21 real, 2.0380 ms/iter, ETA 7:43:18)
p   -polite 0
Iteration 12150000 M( 25786547 )C, 0x646fe55ad6fd8f11, n = 1474560, CUDALucas v2.00a err = 0.06543 (0:54 real, 5.4282 ms/iter, ETA 20:33:06)

The change happens right when the key is pressed. Here's the source code implementing it: (Edit: This is inside the main LL loop, so the getchar() happens once per iteration.)

if (k_f && !quitting && !expectedResidue && (!(j & 15))
	      && _kbhit ())
	    {
	      int c = getchar ();
	      if (c == 'p')
		if (polite_f)
		  {
		    polite_f = 0;
		    printf ("   -polite 0\n");
		  }
		else
		  {
		    polite_f = 1;
		    printf ("   -polite %d\n", polite);
		  }
	      if (c == 't')
		{
		  t_f = 0;
		  printf ("   disable -t\n");
		}
	      if (c == 's')
		if (s_f == 1)
		  {
		    s_f = 2;
		    printf ("   disable -s\n");
		  }
		else if (s_f == 2)
		  {
		    s_f = 1;
		    printf ("   enable -s\n");
		  }
	      fflush (stdin);
	    }

What I'm thinking of for MPrime is to instead check if the char is a number, and if so, then un/pause that worker thread. It would be easy enough to pause multiple workers by pausing them each sequentially, considering pausing a worker would only require a key press. In theory, it might look something like this:

[Worker #1 May 15 18:26:01] Iteration: 39650000 / 54197029 [73.1589%].  Per iteration time: 22.197 ms.
[Worker #2 May 15 18:26:23] Iteration: 13480000 / 25572683 [52.7124%].  Per iteration time: 9.995 ms.
[Worker #3 May 15 18:26:23] Iteration: 25160000 / 25560541 [98.4329%].  Per iteration time: 9.762 ms.
3 [Worker #3 May 15 18:26:34] Stopping primality test of M25560541 at iteration 25161213 [98.4377%]
[Worker #3 May 15 18:26:34] Worker stopped.
[Worker #2 May 15 18:33:11] Iteration: 13520000 / 25572683 [52.8689%].  Per iteration time: 9.619 ms.
[Worker #1 May 15 18:33:41] Iteration: 39670000 / 54197029 [73.1958%].  Per iteration time: 22.102 ms.
[Worker #2 May 15 18:34:46] Iteration: 13530000 / 25572683 [52.9080%].  Per iteration time: 9.511 ms.
[Worker #2 May 15 18:36:22] Iteration: 13540000 / 25572683 [52.9471%].  Per iteration time: 9.548 ms.
[Worker #1 May 15 18:37:28] Iteration: 39680000 / 54197029 [73.2143%].  Per iteration time: 22.698 ms.
[Worker #2 May 15 18:37:57] Iteration: 13550000 / 25572683 [52.9862%].  Per iteration time: 9.515 ms.
3 [Worker #3 May 15 18:38:04] Worker starting
[Worker #3 May 15 18:38:04] Setting affinity to run worker on logical CPU #3
[Worker #3 May 15 18:38:05] Resuming primality test of M25560541 using AVX FFT length 1344K, Pass1=448, Pass2=3K
[Worker #3 May 15 18:38:05] Iteration: 25161214 / 25560541 [98.4377%].
[Worker #2 May 15 18:39:33] Iteration: 13560000 / 25572683 [53.0253%].  Per iteration time: 9.665 ms.
[Worker #3 May 15 18:40:06] Iteration: 25240000 / 25560541 [98.7459%].  Per iteration time: 9.815 ms.
[Worker #2 May 15 18:41:11] Iteration: 13570000 / 25572683 [53.0644%].  Per iteration time: 9.757 ms.
[Worker #1 May 15 18:41:12] Iteration: 39690000 / 54197029 [73.2327%].  Per iteration time: 22.391 ms.
[Worker #3 May 15 18:41:43] Iteration: 25250000 / 25560541 [98.7850%].  Per iteration time: 9.749 ms.
[Worker #2 May 15 18:42:49] Iteration: 13580000 / 25572683 [53.1035%].  Per iteration time: 9.749 ms.
[Worker #3 May 15 18:43:21] Iteration: 25260000 / 25560541 [98.8241%].  Per iteration time: 9.759 ms.
[Worker #2 May 15 18:44:26] Iteration: 13590000 / 25572683 [53.1426%].  Per iteration time: 9.693 ms.
[Worker #1 May 15 18:44:55] Iteration: 39700000 / 54197029 [73.2512%].  Per iteration time: 22.317 ms.

[Prime95]

Build 2 is now available.

[Xyzzy]

http://mersenneforum.org/gimps/

Originally Posted by Prime95

2. Root cause of several false prime reports in recent years found. Fixed in version 27.7 build 2.

Does this possibly affect stress testing at all?

[Dubslow]

Originally Posted by Octopuss

Does this possibly affect stress testing at all?

No. The problem was not with the mathematical part of the program, but rather with the routines to read save files.

[ATH]

Originally Posted by Prime95

2. Root cause of several false prime reports in recent years found. Fixed in version 27.7 build 2.

Was this the save file thing? Or something more? How did you fix it?

[Dubslow]

Originally Posted by ATH

Was this the save file thing? Or something more? How did you fix it?

What would happen is that if none of the save files were read, it was possible to fall into the main LL loop with uninitialized FFT data; now, if I'm reading this correctly, when the program sees a save file but cannot read it or any of the backups, then it outputs a warning: "All intermediate files bad. Temporarily abandoning work unit."; and then it does just that, exiting the LL function, where presumably Prime95 behaves as before and moves onto the next work unit. (It seems like there's a lot of new code; perhaps it should be 27.8?)

The primary code in question is commonb.c, starting at line 5260 for anyone else who's interested.

[NBtarheel_33]

Just a heads-up: The GIMPS home page is still advertising version 26 as the current release build.