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 : Number crunching : Turn off report results immediately to help server load? (Message 160301)
Posted 12 hours ago by Profile Michael GoetzProject donor
Your first mention of it above "<report_results_immediately/>" doesn't parse in my head. There should be two entries with a number inbetween, either 0 or 1.


Syntactically, <report_results_immediately/> is identical to <report_results_immediately>1</report_results_immediately>. It's an XML shorthand. Any code that is parsing XML correctly will accept either. Note the different location of the slash.
2) Message boards : Number crunching : Tour de Primes 2023 (Message 160284)
Posted 15 hours ago by Profile Michael GoetzProject donor
I seem to show a task running:
"1449762265 864841110 5 Feb 2023 | 4:20:37 UTC 10 Feb 2023 | 5:20:37 UTC
In progress --- --- --- Genefer 17 Mega v4.02 (OCLcudaGFN17MEGA)"
That is not on the host.
https://www.primegrid.com/workunit.php?wuid=864841110


That can happen sometimes with the exact right sort of communications glitch. Don't worry about it. It won't affect your computers in any way.

Interestingly, there's a server setting that would correct this. "Why don't we do that?'. you might ask. Because the cure is worse than the disease. While it does fix this (a "problem" we don't care about at all), it causes a much worse problem, that we definitely DO care about: it can cause perfectly valid tasks on your computer to be cancelled. So we live with this one.
3) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160251)
Posted 1 day ago by Profile Michael GoetzProject donor
Who keeps the full list of every single prime ever found?


No such thing.

There's too many to store, and they're too easy to generate. Nobody bothers recording the little stuff.

If you want the first 2 billion primes, just google it and you'll be able to download them. But you won't find anywhere that has everything.

Most of us have probably looked for it at one time or another, only to end up disappointed.

But there must be some record of what areas have been searched, or you guys wouldn't know where to look with the tasks you send out. Do you just have records that say "we've found everything between x and y"?

If the primes found are to make some breakthrough in maths, surely there needs to be records of them? For example one of your projects finds arithmetic progressions.


We search for primes of specific forms only. We do this because those specific forms are easy to search. Otherwise, searching the huge numbers we search would not be possible.

The key part there is "specific forms". You asked about all primes. We have records for the types of primes we search. That's a very small subset of all primes.
4) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160213)
Posted 1 day ago by Profile Michael GoetzProject donor
Who keeps the full list of every single prime ever found?


No such thing.

There's too many to store, and they're too easy to generate. Nobody bothers recording the little stuff.

If you want the first 2 billion primes, just google it and you'll be able to download them. But you won't find anywhere that has everything.

Most of us have probably looked for it at one time or another, only to end up disappointed.
5) Message boards : Number crunching : Tour de Primes 2023 (Message 160191)
Posted 1 day ago by Profile Michael GoetzProject donor
With resource set to 0 I don’t think you can get a cache built up, I can’t anyway. It waits for tasks to finish before getting new tasks in case other projects want work. I guess even though the other projects are set to not get tasks.

I bet the PG servers are getting slammed with all the small 3 second and other small check tasks being constantly sent in .

I bet they are as well.


Those are easy. It's the main tasks -- and the server side processing necessary to then create the small tasks -- that is our concern. This isn't 2008. Server processing of small tasks isn't a problem.
6) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160166)
Posted 2 days 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.
7) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160158)
Posted 2 days 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.
8) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160135)
Posted 2 days 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.
9) Message boards : Generalized Fermat Prime Search : Simple explanation for Genefers and task size? (Message 160123)
Posted 2 days 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.

10) Message boards : Number crunching : Tour de Primes 2023 (Message 160121)
Posted 2 days 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. :)


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 7.85, 7.13, 6.32
Generated 8 Feb 2023 | 10:06:28 UTC