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 Cullen/Woodall prime search : Welcome (back) to the Generalized Cullen/Woodall Prime Search (Message 135074)
Posted 59 days ago by rogue
(Question: Why does Löh say b=32 and b=64 are reserved by PrimeGrid?)


At first I thought it was covered by the GFN search, but that couldn't be the case.
2) Message boards : Project Staging Area : WSS and WFS are suspended (Message 134156)
Posted 89 days ago by rogue
Is anyone actively working on adding double check capability to these searches? What exactly would need to be done to make the work double check-able?


I developed the original code, but have not touched it in a long time. It would require creating a checksum for each workunit. This is not the same as a residue that you get from a PRP test. Such a checksum will slow down the processing a little, but I'm not certain by how much.
3) Message boards : Number crunching : 50 years First ARPANET Connection Challenge (Message 134024)
Posted 94 days ago by rogue
Most communities do trick or treat the Saturday or Sunday before October 31st.
4) Message boards : Project Staging Area : Is it technically possible to move factorial and primorial searches to BOINC? (Message 133948)
Posted 96 days ago by rogue
I can't answer #2.


I would be very surprised if it reached the 2^62 limit. Factorial and primorial sieves are iterative, which means that one must know the result of the previous term before testing the next term. Because of this iterative nature, it takes far longer to sieve a range than non-iterative sieves like ppsieve and srsieve.

It is possible that the older version of fsieve/fsievecl/fpsieve had a limit of 2^52. mfsieve has a limit of 2^62.


One more thing, the CPU threads of mfsieve will use AVX logic for p < 2^52, so it is much faster than fsieve and fpsieve for those p.
5) Message boards : Project Staging Area : Is it technically possible to move factorial and primorial searches to BOINC? (Message 133933)
Posted 97 days ago by rogue
I can't answer #2.


I would be very surprised if it reached the 2^62 limit. Factorial and primorial sieves are iterative, which means that one must know the result of the previous term before testing the next term. Because of this iterative nature, it takes far longer to sieve a range than non-iterative sieves like ppsieve and srsieve.

It is possible that the older version of fsieve/fsievecl/fpsieve had a limit of 2^52. mfsieve has a limit of 2^62.
6) Message boards : Project Staging Area : Is it technically possible to move factorial and primorial searches to BOINC? (Message 133881)
Posted 98 days ago by rogue
In a 2014 thread BOINC vs PRPNet, it was stated:

Primorial and Factorial use PFGW which isn't (currently) supported on BOINC, although we could add the support if we wanted to.


So my question is, is this still the case today?

Would it be straightforward to add support for PFGW in BOINC?

It is my impression that results/residues from factorial and primorial tests on PRPNet are kept and shall be used for doublechecking when/if these subprojects move to BOINC.

I think the factorial and primorial searches would become much more popular if they were moved to BOINC.

/JeppeSN


Jim may correct me if I'm remembering this incorrectly, but there's several non-trivial steps that need to be done.

1) PFGW on BOINC.

I'm sure we'll find some unexpected roadblocks getting that to work, but I'm also confident we'd eventually get it working.

But that success would lead to the second problem:

2) On BOINC, we'd use up the existing sieve files pretty quickly.

We'd have to open up sieving again and sieve to much higher n's this time.

And that takes us to the third problem: (This is where my memory is not as clear.)

3) At least one of the sieves can't go much higher.

So, yes, it's doable. But one of the two projects will quickly come to a close on BOINC not too long after it starts.

EDIT: I neglected to answer your question about double checking. Yes, we have residues, and I suspect we'd probably double-check all the PRPNet work.


Question #1, how would pfgw need to change to support BOINC?

Question #2, how far has the sieving gone? mfsieve (part of the mtsieve framework), which replaced fpsieve/fsieve/fsievecl, can sieve up to 2^62.
7) Message boards : Project Staging Area : PRPNet Help (Message 132771)
Posted 131 days ago by rogue
Try "llrexe=./llrmt.cmd" in prpclient.ini
8) Message boards : Project Staging Area : PRPNet Help (Message 132273)
Posted 151 days ago by rogue
The current prpclient.ini points to https://sourceforge.net/projects/openpfgw/. I don't know which version of PRPNet has the wrong link.
9) Message boards : Project Staging Area : PRPNet Help (Message 132252)
Posted 151 days ago by rogue
So do you need to add a number for the threads you want to use or do you use this in the prpclient.ini

// This sets the CPU affinity for LLR on multi-CPU machines. It defaults to
// -1, which means that LLR can run on an CPU.
cpuaffinity=

Do you put the -T in the pcpclient.ini after the program ?? like:

llrexe=llr64.exe -T
pfgwexe=pfgw64.exe -T


I tried the link in the prpclient.ini to download the pfgw64.exe but it no longer works. I searched google and found this lnk is it the same version ? https://sourceforge.net/projects/openpfgw/files/latest/download


That might work for pfgw64, but I haven't tried. I can't speak for llr.

sourceforge has the latest build of pfgw64. What do you mean "no longer works"? Please be more specific.
10) Message boards : Project Staging Area : PRPNet Help (Message 132207)
Posted 152 days ago by rogue
-T does not work for all tests. Over at mersenneforum there is a thread that indicates which FFTs can take advantage of multi-threading.


Next 10 posts
[Return to PrimeGrid main page]
DNS Powered by DNSEXIT.COM
Copyright © 2005 - 2020 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 3.70, 3.70, 3.79
Generated 21 Jan 2020 | 11:26:44 UTC