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?

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.

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.
____________

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 75898⁵²⁴²⁸⁸+1

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:

http://www.primegrid.com/forum_thread.php?id=6357#86534

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:
http://www.primegrid.com/forum_thread.php?id=6491

Those that show 80 bit for the CPU transform aren't going to be using AVX (or SSE) (currently n=15, n=16, n=17 Low and Mega, n=18, n=19).
Those that show OCL4-high for the GPU transform are going to be slowest for a GPU (currently n=15, n=16, n=17 Mega). Slowest relatively speaking of course, not slowest in absolute terms.

Those last 3 may be a good place to start (and thats where all my non-AVX CPUs are crunching).