New PRPnet drive discussion

[gd_barnes]

Originally Posted by MyDogBuster

Someone correct me on this one. Optimal sieve depth is usually calculated using 1 core sieving to find the depth for 1 core testing. If we have say 20 cores testing, wouldn't the optimal sieve depth be 20 times smaller because you can run 20 times more tests in the same time you could run 1 test?

I wasn't clear on what Max was saying so I thought I would elaborate.

The answer to your question is a clear no in all circumstances. Even if you have 20 cores testing and 1 core sieving, it's still more efficient to sieve to the true optimum depth all of the time (and possibly use a percentage of your cores on other's sieved files; see below). Why? Because sieving is only 5-10% of total test effort. If you are, as you said, only sieving everything to P=500G for testing high limits, you're wasting quite a bit of testing time. In other words, if you wanted to sieve and test all of the time, at all times you should use 1-2 cores sieving while 20 cores are testing, which means you'd spend 5-10% of your total resources sieving. Many people make the mistake of under-sieving because they are in a hurry to find primes.

All of that said, even if sieving were 50% of total test effort, you're still better off using that one sieving core all of the time to sieve to the optimum depth and ONE other core to test all of the time on your own sieved files (i.e. 50% of total CPU effort)...leaving the remaining 18 cores to test what others have already sieved. That is why we have many pre-sieved efforts here. Many people don't have good sievers or they just don't like to sieve and others like Lennart and Mathew like to sieve a lot. I'm kind of in the middle. I like to sieve for a while on 1-3 quads (I have 6 decent sieving quads) but it gets old after a period of time.

I hope this puts it in logical perspective for you.

Edit: For any team drive such as this, we always want to minimize total CPU time because there are very many varied interests here and there is always someone to do what others don't want to do.

[MyDogBuster]

You guys are never going to convince me that sieving to 5T for testing to 200K is saving me time.

I've done plenty of testing on the 1kers to 200K. It takes me 1 day to sieve a base to 500B using 1 core. On an average weight base I get about 4000 tests to run. It would take me another 9 days to get it to 5T. My average test time for 100K to 200K is 1.6 hours. That's 180 tests per day for 12 cores. That's 22 days to test the entire 4000 tests.

By going to 5T on the sieve, I eliminated another 360 tests from the 4000. It would take me 2 days to test those 360, so in other words, I spent 9 more days eliminating something I could have tested in 2 days. Where's the savings? Sure, if I had waited the 10 days for the sieve to finish, it would have taken me only 20 days to fully test the 3640 tests, instead of 22 days.

Assuming I use the 13 cores serially(sieve a base, test a base), it takes me 23 days to do it my way and 30 days to do it your way.

Again, what am I missing here?

I believe the problem is that the sieving programs are skewing the times it takes to eliminate a test. Thousands of tests are eliminated up front and very few on the back end. What we really need to know is how long it is taking to eliminate a test on the back end only. I've seen sieves report that the average elimination time per test is 10 minutes, but the program hasn't eliminated anything in over a hour or 2.

[Lennart]

I realy hope that the sieves not end at 200k !!!

Thats a waste of time.


Sieve should at least go to n=1M


Can you give me 6 bases so I can start sieving ? I don't know wich bases have a sievefile or not.



Lennart

[Lennart]

I have started sieving
r67
r70
r103
r133

n 100k-1M

Lennart

[Lennart]

I have started sieving r158 & r162

r158
n 100k-1M

r162
n 50k-1M

Lennart

[rogue]

Originally Posted by MyDogBuster

I believe the problem is that the sieving programs are skewing the times it takes to eliminate a test. Thousands of tests are eliminated up front and very few on the back end. What we really need to know is how long it is taking to eliminate a test on the back end only. I've seen sieves report that the average elimination time per test is 10 minutes, but the program hasn't eliminated anything in over a hour or 2.

The sieving programs (unfortunately) record the average time for all factors removed. So if you started two days ago, then it will average over those two days. There are a few ways around this to determining the current rate, but the easiest for me was to hack srsieve and sr2sieve so that they report the average time for removal for the most recent 30 factors or so. The only caveat is that it doesn't checkpoint that information so if the sieve is stopped and restarted, it would start with a factor count of 0 for that calculation (total factor count is still correct).

As to what you are missing, it is the fact that you are sieving on one core while PRP testing on multiple cores. If you were to split up sieving across all of your cores (a range of 5e11 per core), then it would take you one day to sieve to 6.5e12 and eliminate two days of PRP testing. In other words, it would take you 21 days (with this method) instead of 23 days to complete that range.

The easier thing to do (rather than switching all of your core between PRPing and sieving) is to dedicate one to sieving and sieve your next range to optimal depth while the others are PRPing your current range.

What I do (and I presume others do something similar) is that since I also have multiple cores (and am using PRPNet), I will stop PRP testing on a core a few weeks before the range is done and begin sieving my next reservation. Once sieving completes, I load it into a server then switch that core back to PRP testing. Note that I do this with two PRPNet servers running and use a 50:50 split between the two in the clients. It takes slightly longer to complete the older reservation, but with single k conjectures I want to avoid the possibility of idle clients if a prime were to be found quickly.

[MyDogBuster]

The sieving programs (unfortunately) record the average time for all factors removed. So if you started two days ago, then it will average over those two days. There are a few ways around this to determining the current rate, but the easiest for me was to hack srsieve and sr2sieve so that they report the average time for removal for the most recent 30 factors or so. The only caveat is that it doesn't checkpoint that information so if the sieve is stopped and restarted, it would start with a factor count of 0 for that calculation (total factor count is still correct).

I have a simple solution for the average time problem. When I see a screen load of 1 minute summaries without an n being eliminated, I've sieved far enough. (Highly scientific). Switching between sieving and PRP'ing is also not fun. I usually dedicate a couple of cores strictly for sieving and the rest for testing.

One other factor, especially on the CRUS stuff, is that once we find a prime, the rest of the tests are eliminated. I know we can't count on finding a prime, but they are found and significant tests are eliminated.

[rogue]

Originally Posted by MyDogBuster

I have a simple solution for the average time problem. When I see a screen load of 1 minute summaries without an n being eliminated, I've sieved far enough. (Highly scientific). Switching between sieving and PRP'ing is also not fun. I usually dedicate a couple of cores strictly for sieving and the rest for testing.

One other factor, especially on the CRUS stuff, is that once we find a prime, the rest of the tests are eliminated. I know we can't count on finding a prime, but they are found and significant tests are eliminated.

I've submitted my change to Geoff for sr5sieve/sr2sieve. Hopefully he will implement it. If not, I will provide source updates to those who are interested. I could even provide a Win32 or Win64 build, but I would prefer that it starts with Geoff.

On a typical search sieving until the removal rate is about 2/3's of the longest PRP test is typically optimal (without a lot of time spent looking at FFT sizes, etc.). For CRUS, if about 30% of the k are removed when going from n to 2n, then a removal rate of about 1/2 is better.

[bdodson]

Originally Posted by rogue

I've submitted my change to Geoff for sr5sieve/sr2sieve. Hopefully he will implement it. If not, I will provide source updates to those who are interested. I could even provide a Win32 or Win64 build, but I would prefer that it starts with Geoff. ...

As long as you're chatting with Geoff, any chance you could ask about
why our teslas give computing errors for Primegrid's ppssieve and gcwsieve?
For example

LD_LIBRARY_PATH=/usr/local.hide/cuda/lib64:$LD_LIBRARY_PATH
./tpsieve-cuda-x86_64-linux -p 100000e9 -P 100001e9 -k 3 -K 9999 -n 2M -N 3M -c60 -t 4

tpsieve version cuda-0.2.3b (testing)
Compiled Jun 25 2011 with GCC 4.1.2 20080704 (Red Hat 4.1.2-48)
nstart=2000000, nstep=34
nstep changed to 32
tpsieve initialized: 3 <= k <= 9999, 2000000 <= n < 3000000
Sieve started: 100000000000000 <= p < 100001000000000
Thread 0 starting
Thread 1 starting
Thread 2 starting
Thread 3 starting
Detected GPU 1: Tesla C2070
Detected compute capability: 2.0
Detected 14 multiprocessors.
Detected GPU 3: Tesla C2050
Detected compute capability: 2.0
Detected 14 multiprocessors.
Detected GPU 0: Tesla C2070
Detected compute capability: 2.0
Detected 14 multiprocessors.
Detected GPU 2: Tesla C2050
Detected compute capability: 2.0
Detected 14 multiprocessors.
Computation Error: no candidates found for p=100000762311649.

Thread 0 completed
Waiting for threads to exit
Thread 2 completed
Thread 3 completed
Thread 1 completed
Sieve complete: 100000000000000 <= p < 100001000000000
Found 0 factors
count=31019409,sum=0x284af85735fd771f
Elapsed time: 15.42 sec. (0.02 init + 15.40 sieve) at 64939957 p/sec.
Processor time: 5.10 sec. (0.02 init + 5.08 sieve) at 197051081 p/sec.
Average processor utilization: 1.03 (init), 0.33 (sieve)

and

>    Does

>    LD_LIBRARY_PATH=/usr/local.hide/cuda/lib64:$LD_LIBRARY_PATH
    ./tpsieve-cuda-x86_64-linux -p 100000e9 -P 100001e9 -k 3 -K 9999 -n 2M >  -N 3M -c60 -t 1 -d X

>    work? X = 1,2,3 or 4 // one card of the 4(?) in the box...

No, doesn't look like it --- no error message, but no factors found
either (much less 73). -Bruce*

-t 1 -d 2

tpsieve version cuda-0.2.3b (testing)
Compiled Jun 25 2011 with GCC 4.1.2 20080704 (Red Hat 4.1.2-48)
nstart=2000000, nstep=34
nstep changed to 32
tpsieve initialized: 3 <= k <= 9999, 2000000 <= n < 3000000
Sieve started: 100000000000000 <= p < 100001000000000
Thread 0 starting
Detected GPU 2: Tesla C2050
Detected compute capability: 2.0
Detected 14 multiprocessors.

Thread 0 completed
Waiting for threads to exit
Sieve complete: 100000000000000 <= p < 100001000000000
Found 0 factors
count=31019409,sum=0x284af85735fd771f
Elapsed time: 58.21 sec. (0.02 init + 58.19 sieve) at 17186248 p/sec.
Processor time: 4.33 sec. (0.02 init + 4.30 sieve) at 232341768 p/sec.
Average processor utilization: 1.08 (init), 0.07 (sieve)
---

LD_LIBRARY_PATH=/usr/local.hide/cuda/lib64:$LD_LIBRARY_PATH ./tpsiev
e-cuda-x86_64-linux -p 100000e9 -P 100001e9 -k 3 -K 9999 -n 2M -N 3M -c60 -t 1 -d 0

tpsieve version cuda-0.2.3b (testing)
Compiled Jun 25 2011 with GCC 4.1.2 20080704 (Red Hat 4.1.2-48)
nstart=2000000, nstep=34
nstep changed to 32
tpsieve initialized: 3 <= k <= 9999, 2000000 <= n < 3000000
Sieve started: 100000000000000 <= p < 100001000000000
Thread 0 starting
Detected GPU 0: Tesla C2070
Detected compute capability: 2.0
Detected 14 multiprocessors.

Thread 0 completed
Waiting for threads to exit
Sieve complete: 100000000000000 <= p < 100001000000000
Found 0 factors
count=31019409,sum=0x284af85735fd771f
Elapsed time: 58.25 sec. (0.02 init + 58.23 sieve) at 17175351 p/sec.
Processor time: 4.48 sec. (0.02 init + 4.46 sieve) at 224418059 p/sec.
Average processor utilization: 1.02 (init), 0.08 (sieve)

Microcruncher* and I seem to be stuck.

(And Greetings! after such a long time since the start of the Rogue-Garo
Tables of Cunningham curve counts. Sorry for the off-topic inquiry.

-bdodson)

[rogue]

Originally Posted by bdodson

As long as you're chatting with Geoff, any chance you could ask about
why our teslas give computing errors for Primegrid's ppssieve and gcwsieve?

Microcruncher* and I seem to be stuck.

(And Greetings! after such a long time since the start of the Rogue-Garo
Tables of Cunningham curve counts. Sorry for the off-topic inquiry.

-bdodson)

I suggest that you contact him at g_w_reynolds at yahoo.co.nz. You would most likely get a faster response.

[gd_barnes]

Originally Posted by MyDogBuster

You guys are never going to convince me that sieving to 5T for testing to 200K is saving me time.

I've done plenty of testing on the 1kers to 200K. It takes me 1 day to sieve a base to 500B using 1 core. On an average weight base I get about 4000 tests to run. It would take me another 9 days to get it to 5T. My average test time for 100K to 200K is 1.6 hours. That's 180 tests per day for 12 cores. That's 22 days to test the entire 4000 tests.

By going to 5T on the sieve, I eliminated another 360 tests from the 4000. It would take me 2 days to test those 360, so in other words, I spent 9 more days eliminating something I could have tested in 2 days. Where's the savings? Sure, if I had waited the 10 days for the sieve to finish, it would have taken me only 20 days to fully test the 3640 tests, instead of 22 days.

Assuming I use the 13 cores serially(sieve a base, test a base), it takes me 23 days to do it my way and 30 days to do it your way.

Again, what am I missing here?

I believe the problem is that the sieving programs are skewing the times it takes to eliminate a test. Thousands of tests are eliminated up front and very few on the back end. What we really need to know is how long it is taking to eliminate a test on the back end only. I've seen sieves report that the average elimination time per test is 10 minutes, but the program hasn't eliminated anything in over a hour or 2.

Ian, you need to take a closer look and watch the sieving programs eliminate the tests. The avg. removal time can be inaccurate and skewed towards the front end BUT if you stop the program, remove some factors, and then restart it with the sieve file, say, at about P=1T, you will get a much more accurate time of factor removal. You should be running your one core sieving all the time while the other 20 cores are testing. If that is the case, on average, it should take close to the same amount of time to sieving as it does to test and there will be CPU time savings.

You are not thinking of CPU time. Think of it like this: If your sieving program eliminates 360 tests in one day it will have saved 20 computers 18 tests each. Yeah, those 20 computers could have done those 360 tests 20 times (i.e. 18 tests each) as fast but in the time that it took them, they could have been working on something else.

Here is what you are ending up with:
1. Let's say you sieve from P=500G to 1T, you eliminate 100 tests, and it takes you one day to do that (24 CPU hours).
2. Since clearly that is not far enough for sieving n=100K-200K, I think it's fair to say that each test would take at least 30 CPU minutes.
3. 100 tests * 30 CPU minutes = 50 CPU hours.

So...you have taken 50 CPU hours to test what could have been eliminated in 24 CPU hours sieving. Those additional 26 CPU hours could have been testing something else in the mean time; perhaps on testing an already-well-sieved base 6 file or something like that.

This is a real example of what is happening to you. Please trust me, only sieving n=100K-200K for high bases to P=500G is wasting a lot of overall CPU time. Lennart and Curtis (at RPS) could quickly confirm this. Even if you have only 1 core for sieving for every 20 cores testing, that's enough. You just have to be patient in getting started.

Edit: Mark also had an excellent example that looked at the inefficiency in a little different way.


Gary