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

Toggle Menu

Join PrimeGrid

Returning Participants


Leader Boards



1) Message boards : Number crunching : Geminids Shower Challenge (Message 152490)
Posted 1 day ago by Profile Michael GoetzProject donor
For the same GPU, the GFN-22 must be faster than the GFN-DYFL, right?

Yes, it is faster and is also fewer credits because it is a smaller number

That's entirely, 100% correct. But it's not the whole story.

GFN-22 is faster and fewer credits than DYFL, and although a part of that is because DYFL is a larger number, that doesn't explain it all.

Currently, at least on my GPU (a GTX 1060), DYFL runs about 32% longer than GFN-22. Calculating the run time based only upon the size of the numbers, I would expect only DYFL to be 26% longer.

That extra 6% is due to the difference in the speed of the transforms. OCL4 on GFN-22, and OCL5 on DYFL.

Because of the difference in transforms speeds, We decided to use a larger credit bonus for DYFL. You get an extra 25% bonus credit on DYFL.

You might ask why the bonus is 25% when the difference in transform speed is only 6%? The answer is... because Nvidia sucks.

When DYFL was started, Nvidia produced GPUs with amazing double precision floating point performance. DP speed is what is needed for scientific calculations. It's not so important for games. Which do you think is more critical for Nvidia's bottom line? The result is that over the years, DP speed has been sacrificed in later Nvidia architectures.

When DYFL was started, and the bonus was established, the benchmarking was done on an Nivida GTX 460, which had blazingly fast DP. The fastest transform made use of that. So the benchmark transform for GFN-22 is OCL, which is (or at least used to be) much, much faster than OCL4.

On a GTX 460, DYFL takes about 50% more time to run than GFN-22. 25% is due to the size of the numbers, and the other 25% is due to the speed difference between OCL and OCL5. To compensate, we gave DYFL 25% extra bonus credit.

While modern Nvidia GPUs are much faster than legacy GPUs, their DP speed isn't proportionally as fast as it used to be. OCL4 is actually faster today than OCL, because DP, and thus OCL, sucks on today's Nvidia GPUs. So instead of comparing a blazingly fast OCL vs OCL5, today, it's OCL4 vs OCL5, and the difference is only 6%.

The bottom line is that DYFL is larger and uses a slower transform, and both make it take longer. Credit is proportionally higher for the size of the number, but currently the difference in transform speed seems to be a lot less than the extra credit bonus. DYFL should therefore do somewhat better than GFN-22 when you look at credit per hour.

2) Message boards : Problems and Help : Task list is not updating as tasks report back and new ones sent out (Message 152435)
Posted 5 days ago by Profile Michael GoetzProject donor
Thanks, it is now up-to-date.
I could see credit being granted and updating the host/total credits but haven't seen the task list not updating before.

We had a problem with the secondary PrimeGrid server, which operates as a replica of the database. It stopped updating, so effectively it was (and is) frozen in time. To increase performance, many of the database pages read from the replica database, so they too were frozen in time.

For now, everything is using the primary database, and is therefore up to date again.
3) Message boards : Problems and Help : Task list is not updating as tasks report back and new ones sent out (Message 152433)
Posted 5 days ago by Profile Michael GoetzProject donor
It should be fixed now. The problem was just in the display on the website. Everything was being processed correctly.
4) Message boards : Problems and Help : Task list is not updating as tasks report back and new ones sent out (Message 152432)
Posted 5 days ago by Profile Michael GoetzProject donor
The task page is correct. The task is complete and credit was granted. The workunit page showing the task as being in progress is wrong. For now, just ignore it while we investigate.
5) Message boards : AP26 - AP27 Search : Constant errors on mobile Quadro GPU (Message 152365)
Posted 12 days ago by Profile Michael GoetzProject donor
I'd suggest to use GPU-Z and check if it shows OpenCL computing capability available.

I'm pretty sure I've run other OpenCL tasks on this laptop in the past, but GPU-Z does say that it doesn't have OpenCL support now. I don't know why unless it was removed in the newer drivers. Or I'm just remembering incorrectly...

Try reinstalling the drivers. Windows updates can cause this problem.
6) Message boards : Number crunching : Calculating FFT length (Message 152335)
Posted 14 days ago by Profile Michael GoetzProject donor
How is FFT length calculated? Is is solely based on the the prime being calculated or are there other external factors such as hardware that can affect the FFT being used? And is the choosing of the FFT dynamic? (I am not asking about fitting a given FFT into cache which is covered in other threads.)

tl;dr: It's the number and the CPU type, but the details are very complicated.

The number (magnitude, size of the component parts, and I believe the type of number) and the hardware (CPU architecture) both have a role in selecting the FFT size.

The software tries to pick the fastest (usually the smallest) FFT size and FFT type. It guesses what it thinks the best FFT is, and uses that. If it guesses too aggressively and uses an FFT that is too small, a loss of precision will occur due to rounding errors, which will be detected, and all or part of the calculation will be retried with the next larger FFT.

If the guess is not aggressive enough, then a larger (i.e., slower) FFT is used when a faster FFT would have worked.

It works pretty well, but it's not an exact science.

Note that if you're using multithreading, it's even more complicated because the "best" size (i.e., smallest FFT that won't cause an error overflow) is **NOT** deterministic. Because threads will complete in random order, when you're close to an FFT boundary, some orderings of threads completing may produce an error overflow while other orderings won't. Here's an example...

Suppose there's four threads, and each produces an error of either +1 or -1, that the maximum allowable error is +2 (+2 is ok, but +3 is failure), and that three of the threads produce an error of +1 while one thread produces an error of -1. Consider these two orderings of how the four threads complete:

ordering one:
+1 (cumulative error +1, ok)
-1 (cumulative error 0, ok)
+1 (cumulative error +1, ok)
+1 (cumulative error +2, ok)

ordering two:
+1 (cumulative error +1, ok)
+1 (cumulative error +2, ok)
+1 (cumulative error +3, CALCULATION FAILS)
-1 (don't care)

In the second ordering, the result of the calculation has incurred too much rounding error to be considered valid, but if the threads complete in a different order, the calculation is valid.

That's not exactly how the error calculation works, but it's close enough to demonstrate why multithreading makes the rounding errors non-deterministic.
7) Message boards : Generalized Fermat Prime Search : GFN-17-LOW will finish soon (Message 152265)
Posted 20 days ago by Profile Michael GoetzProject donor
I'm sure there is and I'm just not able to figure it out, but how do I tell how many GNF-17 tasks I personally have done (both 1st and 2nd)?

There isn't. At least there isn't an easy way. The server stores the *total* number of Genefer tasks you've run, but it doesn't break it down to individual GFN sub-projects. Nor does it record whether you're first or not.

The best you can do is look at the log on your computer that lists every task that was run. On a Windows computer, the log is C:\ProgramData\BOINC\

That will tell you which tasks you've run, but there's no place you can get historical information about whether those tasks were first or not.
8) Message boards : General discussion : Suggestions for 2022 challenges (Message 152259)
Posted 21 days ago by Profile Michael GoetzProject donor
Terry Pratchett wrote:
"A chance in a million happens nine times out of ten"
Clever man.
He didn't say which chance in a million.

If you're "one in a million", that means there's seven thousand people exactly like you!
9) Message boards : News : GFN-17-Low is finishing (Message 152257)
Posted 21 days ago by Profile Michael GoetzProject donor
The GFN-17-LOW project has less than a million candidates to be tested, and thus will come to an end in the next few months.

Forum discussion thread:
10) Message boards : Generalized Fermat Prime Search : GFN-17-LOW will finish soon (Message 152256)
Posted 21 days ago by Profile Michael GoetzProject donor
This is the official warning for the sub-project end.

Consider this to be the official 30 day warning, although it's probably closer to 4 months than to 1 month. It all depends on how much people run 17-low, and as we get closer to the end more and more people will pile onto 17-low. I am therefore giving you the warning early.

There's less than a million candidates to go, and we're currently doing about 15K tasks per day (2 tasks per candidate.)

Next 10 posts
[Return to PrimeGrid main page]
Copyright © 2005 - 2021 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 2.47, 3.62, 3.65
Generated 5 Dec 2021 | 20:38:26 UTC