## Other

drummers-lowrise

Message boards : Sophie Germain Prime Search : Search vs Verify

 Subscribe SortOldest firstNewest firstHighest rated posts first
Author Message
Christian Keimer

Joined: 3 Jan 16
Posts: 9
ID: 434905
Credit: 14,944,072
RAC: 0

Message 99285 - Posted: 30 Sep 2016 | 12:00:53 UTC

Hi,

I do have one question to the Sophie Germain Prime Search.

In the official announcement of a new prime there is always the name of the discoverer and the name of the verifier.

Can you tell by the name of the work unit which unit is a search for the prime or if a work unit just verifies a result? Has this something to do with the ending of the file e.g. _0 or _1?

Will you ever find a prime if you just crunch files with the ending of _1?

Thank you very much and have a great weekend!

Cheers,
Chris

____________
My lucky number is 113912436^65536+1

Pooh Bear 27

Joined: 10 May 09
Posts: 800
ID: 39821
Credit: 1,828,276,165
RAC: 2,141,816

Message 99286 - Posted: 30 Sep 2016 | 12:24:32 UTC - in response to Message 99285.

The first person to correctly send it back will be the finder. Does not matter the number at the end. That is just the iteration that was sent out. If a unit failed 5 times, someone got _5 and then 4 more fails and you got _10, you returned yours before the person with _5, you are the finder. Plain and simple.

Good luck in finding primes.

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13956
ID: 53948
Credit: 393,166,793
RAC: 184,751

Message 99292 - Posted: 30 Sep 2016 | 13:18:42 UTC - in response to Message 99285.

Can you tell by the name of the work unit which unit is a search for the prime or if a work unit just verifies a result? Has this something to do with the ending of the file e.g. _0 or _1?

Will you ever find a prime if you just crunch files with the ending of _1?

That's a really good question! A lot of other prime-hunting projects send out first-pass and second-pass work separately. We do not work that way.

We send out two copies of each test simultaneously, and whomever returns the task first if the prime finder. Sometimes only minutes or just seconds separate the prime finder and the double checker.

____________
My lucky number is 75898524288+1

Christian Keimer

Joined: 3 Jan 16
Posts: 9
ID: 434905
Credit: 14,944,072
RAC: 0

Message 99295 - Posted: 30 Sep 2016 | 13:44:06 UTC - in response to Message 99292.

We send out two copies of each test simultaneously, and whomever returns the task first if the prime finder. Sometimes only minutes or just seconds separate the prime finder and the double checker.

Unfortunately that brings me to the conclusion that I will not continue with this project since, my computers take about 1h30min to finish a work unit and I crunch other projects simultaneously.

None of my last 20 returned work units “beat” the other cruncher, therefore there is no chance that someone like me will ever find a prime in this project.
And someone who is crushing a _2, _3, or _4 file will probably also will never find a prime with that work unit.

Someone could argue that this process is not a fair competition. It clearly favors “pro-crunchers” and “hobby-crushers” like me need to look for another project to contribute.

That is a little bit sad, but I wish you all good luck in your search.

Chris

____________
My lucky number is 113912436^65536+1

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13956
ID: 53948
Credit: 393,166,793
RAC: 184,751

Message 99296 - Posted: 30 Sep 2016 | 14:24:50 UTC - in response to Message 99295.

And someone who is crushing a _2, _3, or _4 file will probably also will never find a prime with that work unit.

Yes, having a faster computer is an advantage, but setting your cache to 0 is just as important. I can show you lots of examples of tasks computed on CPUs being returned before GPU tasks. Is it less likely? of course. But it happens a lot.

The part about "_2, _3, or _4 file will probably also will never find a prime" is completely false. For a variety of reasons tasks fail, or simply never returned, and duplicate tasks are sent out. On some longer tasks, it's not uncommon to see task counts in the 40's or 50's.

I looked at your computers. Yes, they're a bit old and they're not monster crunching machines, but you can at least triple your chances of finding a prime by setting your BOINC cache to 0. That one change would effectively get your tasks returned 3 hours earlier. Considering it only takes about 90 minutes to finish a task, that a big improvement.

(Most of the time, especially with short tasks, people are the double checker not because their computer is slow but because they're running with a larger BOINC cache than the other person.)

Someone could argue that this process is not a fair competition.

If by "not fair", you mean that people with fast computers, or more computers, or more money (with which to buy or rent computers) have an advantage, then of course that's true.

Here are some primes that were not only found by slower computers, but the prime was actually found on a CPU while the double checker was using a much faster GPU. (Typically 40 times faster):

This one is a longer task (n=65536). This prime was also discovered on the CPU, and the double checker used a GPU:

Especially with short primes, there's lots of examples where slower computers finished first. The difference in speed of the computers is dwarfed by the amount of time tasks spend languishing in the BOINC cache waiting to run. You might not be able to change how fast your computer runs, but you have complete control over the size of the BOINC cache. You can drastically speed up how fast your computer returns tasks with a few mouse clicks.
____________
My lucky number is 75898524288+1

Michael Millerick
Volunteer tester

Joined: 4 Feb 09
Posts: 929
ID: 35074
Credit: 833,491,363
RAC: 986,616

Message 99299 - Posted: 30 Sep 2016 | 15:23:24 UTC

I like to take joy in the overall project finding primes and setting records. Individually, a lot of PrimeGrid's findings would have been impossible for any one of us to achieve on our own, but collectively, we are making some great progress. If I hadn't completed the 31000 SGS that my computers ran, then we would be that much farther behind in the total SGS work. If no one ran SGS because the odds of them being the one to find the record twin/SGS prime was so small, then we probably wouldn't have found the record primes that we have found as a group.

Every work unit completed here counts in some way, shape, or form. Particularly for the conjecture projects, where every work unit completed gets us closer to work units that will find a prime and reduce the number of k's that tests are being run for. You may want to shift over to those (TRP, ESP, PSP, SoB, SR5) since there is one large goal there outside of individual prime finds.
____________

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13956
ID: 53948
Credit: 393,166,793
RAC: 184,751

Message 99496 - Posted: 4 Oct 2016 | 17:11:55 UTC

I know this example is an aberration. I'm running SGS on this computer just to get a few more tasks for the challenge.

Nevertheless, this is a Sempron (single core, 32-bit, no FMA3, no AVX, not even SSE3, all it has is x87) vs. a Haswell 4770K.

http://www.primegrid.com/workunit.php?wuid=499217164

The Sempron won. :)

Out of 8 tasks during the challenge, that's the only one that finished first. That's not bad for such an ancient computer.
____________
My lucky number is 75898524288+1

Christian Keimer

Joined: 3 Jan 16
Posts: 9
ID: 434905
Credit: 14,944,072
RAC: 0

Message 99688 - Posted: 9 Oct 2016 | 10:40:05 UTC - in response to Message 99296.

setting your cache to 0 is just as important.

I did some testing prior to the “World Space Week Kickoff Challenge” and during it.

Prior to the challenge I crunched 27 WU with the cache set to 0.

For 21 WUs my computer was slower than my “opponent”. I faced “opponents” with an average CPU time of 1,644 sec (compared to my 5,500 sec).
The 6 WUs I “won”, 5 of them I “won” because the “opponent” didn’t set their cache to 0 and I “won” only one WUs because it was done by someone that had an even slower computer then I have.
So I had only a success chance of 22% to beat my “opponents”.

During the challenge I won 20 WUs (42%) and lost 27 WUs. There was only one computer that was slower than my computer, all other wins came from opponents that participated or switch to that project for the challenge without setting their cache to 0. I faced “opponents” with an average CPU time of 1,233 sec.

My conclusion is, that during non-challenge times with “professional” working with their fast computers on that project, for me with a goal oriented mindset (to find a prime) it doesn’t make sense to “compete” against most of you.

My point is just that with an indefinite number of primes out there, why do we need to “compete” against each other to find them? Isn’t the purpose of distributed computing project to work together to reach a solution or more knowledge?
If you have a fast machine, you will still crunch more WUs and have a far higher chance to find a prime, then hobby crushers like me.

Just my thoughts…

Cheers,

Chris

____________
My lucky number is 113912436^65536+1

Van Zimmerman
Volunteer tester

Joined: 30 Aug 12
Posts: 1950
ID: 168418
Credit: 6,315,554,899
RAC: 0

Message 99692 - Posted: 9 Oct 2016 | 17:55:56 UTC

We are all volunteer crunchers here. Without the double-checks, there is the potential to "miss" primes in ranges of numbers. With the double-checks, we can be much more certain that when a range is "done", that there are no more primes there left to find.

One of my rather ancient machines made a decent GFN find last year using its cpu:

If I recall correctly, it beat out a faster machine to the deadline by 15 minutes or so.

That machine is even older now but still crunching away:

http://www.primegrid.com/show_host_detail.php?hostid=478753

It is certainly the double-checker on many work units, but that is also work that has to be done.

Project selection can play a big difference in minimizing the advantage faster cpus have (and to some extent gpus).

The LLR projects (like SGS) are probably not the best choice, since LLR will use AVX if available and this gives newer CPUs a significant advantage.

Some of the Genefer projects, however, have progressed to a point where
1) CPUs can't use AVX
2) GPUs have to use slow, or the slowest available computations
3) Because of 1 and 2, some people are less likely to point newer/faster hardware at these projects.

Mr. Goetz keeps the first post in this thread updated as to where the "b" values for the various "n" GFN projects are, and what this means for CPU transform and GPU transform: