PrimeGrid
Please visit donation page to help the project cover running costs for this month

Toggle Menu

Join PrimeGrid

Returning Participants

Community

Leader Boards

Results

Other

drummers-lowrise
1) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160166)
Posted 12 hours ago by Profile Michael GoetzProject donor
No, what I'm looking for is for one computer (say a test one at Primegrid) to have run one of every task, so you can say a genefer 15 takes 1 minute, a genefer 16 takes 4 minutes, etc.

It may not be exactly 4 times longer on my computer, but it's a good enough estimate if you're looking to pick a subproject that takes x amount of time. And if you named the GPU used for the test, I could decide my card is probably half the speed of that and adjust the numebrs accordingly.


Three problems, and the reason I said it's a nightmare. And the reason we don't do it.

The first is that the tasks change, sometimes rapidly. The benchmarks need to be rerun, as needed. It's not a one-time thing. It's an ongoing maintenance issue.

The second problem is that the servers are to busy to spend time running benchmarks; shared cloud computers are unsuitable for running benchmarks, and our personal computers both tend to change, and we have other things we want to do than to run one of everything. That takes a lot of time. Running benchmarks isn't trivial; to insure good data you have to make sure the conditions are consistent. That means the compute must be in an identical condition for each test, preferably otherwise idle. Between CPUs and GPUs, that's a lot of tasks, a lot of time, and a lot of wasted CPU cycles.

The third problem is that different tasks within a sub-project can have significantly different run times.

If it was easy, trust me, we'd have done it.
2) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160158)
Posted 15 hours ago by Profile Michael GoetzProject donor
Ah, it would be more helpfull if this showed "time to complete on a (insert a GPU model)" then they could be compared directly to each other and also to your own card.


Indeed, it would. But maintaining such statistics would be a nightmare.

Besides, every computer is different in myriad ways, from motherboard chipset to RAM timings. The timings on someone else's computer, even with the same CPU, might be significantly different than the timings on your computer. Even with better statistics you're still left with the unpleasant truth: If you really want to know how fast it will run on *your* computer, you are going to have to test it on *your* computer. Even which task is faster can vary from computer to computer.

We do have a page (https://www.primegrid.com/gpu_list.php) that collects statistics on each GPU model and how fast it runs each of our GPU tasks. Exactly what you want, right? Maybe not so much. There's so much variance in performance between supposedly identical devices that the data is not nearly as useful as you would expect. The sad reality is the best way to get good data is to run your own tests.
3) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160135)
Posted 17 hours ago by Profile Michael GoetzProject donor
Do the number of them found slow down as you get to larger numbers? I don't mean take longer to calculate, I mean get further and further apart tending towards there will never be another one?


Yes they do.

However, within a singe "n", GFN numbers grow very slowly, so the rate at which primes become rarer is also very slow.

But when you go from, say, GFN-15 to GFN-16, for example, the primes become about twice as rare, in addition to taking four times as long to test each candidate.
4) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160123)
Posted 19 hours ago by Profile Michael GoetzProject donor
Does the project itself have an opinion on which are the most important ones to search for?


We would like to find a GFN-21. None are yet known. So that's a priority.

Likewise, we would like to find a GFN-22. There's none of these that have been discovered yet either. It's also a priority.

Finally, DYFL -- essentially GFN-22 but with much higher b values -- is a priority because, if found, it would be the world's largest known prime.

And is there anything useful to come from these numbers - presumably any correlation of things in maths is asking for a eureka moment and the furthering of everything in general.


While some other projects have a mathematical objective, such as proving the Sierpinski conjecture, this one does not. However, there are two goals common to all the projects: educating participants, and advancing software science. The drive to find primes more efficiently has led to several significant software advances. Granted, these advances are primarily useful when searching for primes, but who knows when something will be found to be of use in some other disciple. Who knew that going to the moon would give us Velcro?

It's very irritating to have wasted a few days computation on a corrupted genefer extreme.


That's a large part of the reason we grant so much credit to running long tasks like that.

To both of you, are the numbers in a range infinite or not? You seem to disagree.


Infinite. I assure you there's no disagreement. :) GFNs are of the form B2N+1, so for every GFN, there's another one at (B+2)2N+1. However, how many GFN primes exist is not known, but is believed to be infinite. But that is not proven.

5) Message boards : Number crunching : Tour de Primes 2023 (Message 160121)
Posted 19 hours ago by Profile Michael GoetzProject donor
Just went to the basement to start some laundry and turning on the basement lights tripped a breaker. Oops.

Time to shuffle some systems around the house and maybe redistribute some GPUs.


That would be very scary if it was a single LED bulb in the basement. :)
6) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160113)
Posted 20 hours ago by Profile Michael GoetzProject donor
I'm not a mathematician. I've got a degree in Physics, so I can do some maths, but not to the level of this project. Keeping that in mind, can someone provide dumbed down answers?

I know the Genefer 20 tasks are much bigger than the Genefer 15 tasks, there's a 2^20 or 2^15 somewhere in the range you're looking in.

My two questions are:

1) Why are the tasks monumentally different sizes? Is each task looking for a single prime number, so the 20s take much longer than the 15s? If they're looking for several, can they not be split into smaller tasks?

2) Why aren't there massively less primes to look for in the 15 so it should be finished by now? And on the main page, we see bigger queues for the smaller genefers.


Great questions, Peter. Thanks for asking.

1) Why are the tasks monumentally different sizes?


The processing time for a number, assuming all else is equal, is roughly proportional to the square of the number of digits in the number. As it turns out, when you go from GFN-15 to GFN-16, the number of digits doubles. That means the processing time quadruples. So GFN-16 takes 4x as long as GFN-15, GFN-17 takes 16x as long, GFN-18 takes 64x as long, GFN-19 takes 256x as long, GFN-20 takes 1024x as long, GFN-21 takes 4096 times as long, and GFN-22 takes 16,384 as long as a GFN-15.

Is each task looking for a single prime number, so the 20s take much longer than the 15s?


Yes, at PrimeGrid, each task does a single number.

Why aren't there massively less primes to look for in the 15 so it should be finished by now?


There's believed to be an infinite number of primes at each GFN level. However, they are much easier to find at the lower GFNs. The projects can go on forever, so long as the software is able to handle the numbers in questions. The software does have limits, however, the developer of Genefer, the program we use to test GFNs, is actively maintaining the software and has been updating Genefer so that we can continue using it as the numbers grow larger.

And on the main page, we see bigger queues for the smaller genefers.


Correct. Those are not the total number of remaining tests. There's an infinite number of possible tests. It's not even the total number of available tests. It's merely what we have loaded into the server right now. We keep the number of loaded tasks low so that the database is a manageable size. There's more tests loaded for the smaller GFNs because they run much quicker, so we need a bigger supply of them to service customer requests for more work.
7) Message boards : Number crunching : Turn off report results immediately to help server load? (Message 160111)
Posted 20 hours ago by Profile Michael GoetzProject donor
Now we're all first because of the new fast-checking algorithms, is there any need for reporting results immediately? It might ease the server load (if there is one). Of course anyone who objects would be free to set this parameter locally.


It won't affect the server load either way, so set it however you want. More specifically, while it will indeed lower the server load by some measurable amount, this isn't what causes problems. It is the validation on the main tasks that is resource intensive, not servicing the RPCs from your computers. It won't make a difference whether you have it on or off.

Personally, I'm leaving it on because I do run SGS from time to time, and both SGS and GFN-15 still don't have FAST-DC so being first is still a race. If I turn it off, I won't remember to turn it back on when I need it.
8) Message boards : Number crunching : Tour de Primes 2023 (Message 160083)
Posted 2 days ago by Profile Michael GoetzProject donor
OK, answers...

First of all, all of those are VALID.

Unusual, but everything's ok.

Some of you will remember that there used to be a system where if we already had one residue from another source, your task would match directly against the residue without the need for a wingman. With LLR2 and fast DC, that works differently now, but that system still exists.

All of those tasks matched against a residue already in our database. LLR2 tasks return not only the LLR2 proof data; they also return the old-style residue. If that residue matches something in our database, we use that and don't bother creating a fast DC task. Your task gets fully validated immediately, with no DC task.

In the case of the k=27 tasks, those residues are from PRPNet.

The others just happen to have been in our database. It's usually difficult to track where those came from.
9) Message boards : Number crunching : Tour de Primes 2023 (Message 160069)
Posted 2 days ago by Profile Michael GoetzProject donor
Why some tasks are validated without DC WUs?
https://www.primegrid.com/workunit.php?wuid=862638390


You said "tasks", plural. I could not find any examples other than the one you provided. Are there more?
10) Message boards : Number crunching : Tour de Primes 2023 (Message 160067)
Posted 2 days ago by Profile Michael GoetzProject donor
Why some tasks are validated without DC WUs?
https://www.primegrid.com/workunit.php?wuid=862638390


That's a really good question. I'll find out.


Next 10 posts
[Return to PrimeGrid main page]
DNS Powered by DNSEXIT.COM
Copyright © 2005 - 2023 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 11.32, 11.39, 10.79
Generated 6 Feb 2023 | 12:24:13 UTC