Prime Gap Search latest version of the c code

[Thomas11]

I did another test on a machine equipped with 128 GB, and it turns out that for this amount of memory the entire n range of 1e18 (e.g. 6-7e18) will no longer be split into parts. Actually it used only 54.19 GB.

So I went a little further and obtained the necessary minimum memory requirements for different [n1,n2] interval sizes (without splitting into parts):

n2-n1  memory
2e18   90.28 GB
1e18   54.19 GB
5e17   36.15 GB
2.5e17 27.14 GB
2e17   25.32 GB
1e17   21.72 GB

Thus, a quarter range like 6e18-6.25e18 might fit into 32 GB memory.

[ET_]

Originally Posted by Thomas11

I did another test on a machine equipped with 128 GB, and it turns out that for this amount of memory the entire n range of 1e18 (e.g. 6-7e18) will no longer be split into parts. Actually it used only 54.19 GB.

So I went a little further and obtained the necessary minimum memory requirements for different [n1,n2] interval sizes (without splitting into parts):

n2-n1  memory
2e18   90.28 GB
1e18   54.19 GB
5e17   36.15 GB
2.5e17 27.14 GB
2e17   25.32 GB
1e17   21.72 GB

Thus, a quarter range like 6e18-6.25e18 might fit into 32 GB memory.

...and people like me, with only 2 threads and 2 GB of RAM, will be cut ou of the search. Oh, well...

[pinhodecarlos]

Originally Posted by ET_

...and people like me, with only 2 threads and 2 GB of RAM, will be cut ou of the search. Oh, well...

use the old client

[ET_]

Originally Posted by pinhodecarlos

use the old client

I will. I was just waiting until the new code restrictions were published.
Still wonder if a double reservation (client v.5 and client v.9) can be held...

[robert44444uk]

Originally Posted by ET_

...and people like me, with only 2 threads and 2 GB of RAM, will be cut ou of the search. Oh, well...

I don't think so, we are only talking about whether -res will go through 1 cycle or more than one cycle, the way I understand it

I am running the new client on an underpowered lap top with 2.6 G memory and 3 threads. Its working fine but -res is going through several cycles. You still get an ETA which will be accurate.

[robert44444uk]

Originally Posted by ET_

I will. I was just waiting until the new code restrictions were published.
Still wonder if a double reservation (client v.5 and client v.9) can be held...

No it won't be possible within 6e18 to 7e18. Of course there are still unreserved ranges in 5e18 to 6e18 :) But see my post #82 above about small computers.

[R. Gerbicz]

Here it is gapcheck.c to verify the completed works, it is also printing the missing works.
Furthermore this needs the log files in the program's directory, but its name can be anything, the extension should be .txt; it is checking all txt files.

[Antonio]

Originally Posted by ET_

...and people like me, with only 2 threads and 2 GB of RAM, will be cut ou of the search. Oh, well...

Just tried it on my laptop (i7-6700HQ @ 3.2GHz) for you:

gap9_haswell -n1 7e18 -n2 8e18 -n 7e18 -res1 0 -res2 10 -res 0 -m1 1190 -m2 8151 -numcoprime 27 -sb 24 -bs 18 -t 2 -mem 2

Got about 5.85e9n/sec, ETA 58hours

[R. Gerbicz]

Originally Posted by Antonio

The program splits the k range into sub-ranges to fit what it can in memory and tests each subrange for the res requested, so yes, what you are seeing is probably correct.

Yes, that is true.

Originally Posted by Thomas11

We need also to keep an eye on n, in particular when transferring a range to a different machine. If the new one has a less memory than the original one, we might be missing some subintervals...

gap9 handle this. But yes, it isn't very efficient to copy every hour the worktodo file to a slower computer, then back. It is better to give a smaller res interval to a small computer with small memory. And a longer res interval to a faster computer.

Originally Posted by Thomas11

I did another test on a machine equipped with 128 GB, and it turns out that for this amount of memory the entire n range of 1e18 (e.g. 6-7e18) will no longer be split into parts. Actually it used only 54.19 GB.

Yes, but the speedup would be small in this case.

Originally Posted by robert44444uk

I am running the new client on an underpowered lap top with 2.6 G memory and 3 threads. Its working fine but -res is going through several cycles. You still get an ETA which will be accurate.

In the new version removed an unneeded lower bound on size, so on these computers with save_nextprimetest=0 we need fewer memory than gap5. Ofcourse with larger memory use save_nextprimetest=1 to get a higher sieve rate.

[ET_]

Originally Posted by Antonio

Just tried it on my laptop (i7-6700HQ @ 3.2GHz) for you:

gap9_haswell -n1 7e18 -n2 8e18 -n 7e18 -res1 0 -res2 10 -res 0 -m1 1190 -m2 8151 -numcoprime 27 -sb 24 -bs 18 -t 2 -mem 2

Got about 5.85e9n/sec, ETA 58hours

I'll take it, thanks!

[Thomas11]

Originally Posted by R. Gerbicz

Here it is gapcheck.c to verify the completed works, it is also printing the missing works.
Furthermore this needs the log files in the program's directory, but its name can be anything, the extension should be .txt; it is checking all txt files.

I did a few tests, and it correctly detected and reported the missing ranges.