![]() |
![]() |
#309 | |
P90 years forever!
Aug 2002
Yeehaw, FL
3·11·223 Posts |
![]() Quote:
1) Uses AVX 2240K FFT. That's near an FFT limit and AVX is likely less tested. 2) Early in stage 2 there was a restart due to mem change. 3) The roundoff error and backtracking. I need to look at all 3 to see if I can replicate any issues. The next build is near ready. I'd like to investigate this possible bug first. Nordi's crash on start up and crash due to excessive memory allocation are the only other bugs I've not been able to figure out. I think nordi should mail me his 32-core machine :) |
|
![]() |
![]() |
![]() |
#310 |
1976 Toyota Corona years forever!
"Wayne"
Nov 2006
Saskatchewan, Canada
5×911 Posts |
![]()
Since last update (November 08)
30 more ranges cleared: 3.1, 3.6, 4.8, 5.1, 5.6, 5.7, 5.8, 6.3, 9.3, 16.6, 20.4, 21.1, 29.1, 30.2, 30.3, 31.6, 32.5, 33.0, 34.6, 34.9, 35.5, 38.0, 38.2, 38.6, 38.9, 39.3, 44.6, 46.3, 47.8, 49.4 And 1 bonus ranges: 58.7. TOTALS to date: 225 total ranges cleared or 45.27% 3 Ranges with less than 20 to go. 1,486 more factored (27,075)....49.02% total factored. So confidently expecting every higher range to be cleared by natural GIMPS work I can now report the: Top-End is 49.6 Bottom-End is: 3.2 Only 8 ranges remaining in the 40Millions. I will be doing aggressive P-1 on these until about mid 2021. Then they will require TF to 75; and a few to 76 bits. Or, with a little coordination it would be fine to TF these to 75 any time. Only 20 ranges remaining in the 30Millions. A few of you are helping with P1 and TF there. More P-1 help would be useful here. Continuing to get lots of great help. THANKS Thanks again for everyone contributing. |
![]() |
![]() |
![]() |
#311 |
P90 years forever!
Aug 2002
Yeehaw, FL
3×11×223 Posts |
![]()
Build 4 is ready. A few bug fixes, a little less memory usage in ECM stage 2 -- maybe that will help nordi. No luck finding a cause for petrw1's errant P-1 run.
Win64: https://www.dropbox.com/s/epf2eqdn00...win64.zip?dl=0 Linux64: https://www.dropbox.com/s/fh4dq51w7f...64.tar.gz?dl=0 I hope this will be the last build announced in this thread. Thanks for everyone's help in locating several bugs. |
![]() |
![]() |
![]() |
#312 | |
1976 Toyota Corona years forever!
"Wayne"
Nov 2006
Saskatchewan, Canada
10001110010112 Posts |
![]() Quote:
To upgrade can I only replace prime95.exe or do I need any other files? |
|
![]() |
![]() |
![]() |
#313 |
P90 years forever!
Aug 2002
Yeehaw, FL
162778 Posts |
![]()
Replace the .exe is fine
|
![]() |
![]() |
![]() |
#314 |
1976 Toyota Corona years forever!
"Wayne"
Nov 2006
Saskatchewan, Canada
5×911 Posts |
![]()
I upgraded 1 PC from b3 to b4. I replaced all the files.
Before I continue; first Windows and then AVG (my antivirus software) asked if I was sure I trusted it; which I said I did: "Run Anyway". In my rush I may have double-clicked it a few times to start it and get the window to pop up. ANYWAY... Then I spent 5 minutes waiting for it to respond; then waiting 30 minutes for Task Manager to respond to tell me what was going on. When TM finally responded I saw 3 Prime95 sessions running and 3 more seemingly idling. After another 10 minutes I was able to Stop/Exit the one I could see. That left 2 more plus the 3 idlers in Task Manager. I could force stop the 2 more active; but the other 3 didn't go away. I rebooted and all is well now. Even though all 3 sessions were using 20-40% CPU there is no evidence of other work files; could all 3 have been processing the same P-1 without messing each other up? Tomorrow I'll try to start it again while it is still running and see if I get more than 1 again. |
![]() |
![]() |
![]() |
#315 |
1976 Toyota Corona years forever!
"Wayne"
Nov 2006
Saskatchewan, Canada
5·911 Posts |
![]() |
![]() |
![]() |
![]() |
#316 |
P90 years forever!
Aug 2002
Yeehaw, FL
11100101111112 Posts |
![]()
Back when I knew how to write Windows programs (95/98/me/XP), prime95 was written such that running a second prime95 would simply make the first prime95 active in case the program was minimized and then exit. It sounds like that code no longer works.
Last fiddled with by Prime95 on 2021-01-02 at 19:05 |
![]() |
![]() |
![]() |
#317 |
Sep 2002
Oeiras, Portugal
23×181 Posts |
![]()
@George:
I´ve just installed and tried build 4 on a win64 machine with 4 cores and 16 GB RAM. The following applies to ECM testing only. I have not yet tried P-1. I made 10GB available to Prime95 With build 3, the 4 workers (1 core each) would share the 10 GB among them, using up the available memory, that was set to 10 GB as well.) Now, I notice that the workers are using a lot less memory, even though tthey were allowed to use more. An example: I am ECMing 4 exponents in the 547xxx range. With only 1 worker running stage 2, the program says it will use 4912 MB of memory, but looking at Task Manager, one sees that the used memory starts going up to the expected number (a little more than 5GB, which is reasonable given there are other workers running) but then it goes down to around 3.6 GB. When a second worker enters stage 2, it also indicates it will be using 4912 GB, the figure for mem used climbs to just over 8 GB and then goes down to just under 7GB and stabilizes there. When the third one joins, it will just use 416 MB, the ratio B2/B1 is 117 instead of 154 for the first two workers, and the stage 2 takes less than half the time. The total memory used is around 7.5 GB, well under the allowed limit. I don´t know whether or not this is the expected behaviour, but it seems to me the memory is underused, so I thought it was better to let you know, as this might have an impact on the probability of finding factors. |
![]() |
![]() |
![]() |
#318 |
1976 Toyota Corona years forever!
"Wayne"
Nov 2006
Saskatchewan, Canada
5·911 Posts |
![]()
More likely your code is fine but Windows Alerts/AVG got in the way.
|
![]() |
![]() |
![]() |
#319 | |
P90 years forever!
Aug 2002
Yeehaw, FL
735910 Posts |
![]() Quote:
Stage 2 steps from B1 to B2 in increments of D. Each of these increments requires a very, very expensive modular inverse. However, N modular inverses can be pooled together using 3N multiplications and 1 modular inverse. This pooling requires 2N temporaries (the N multiples of D that will be processed one at a time and N temporaries that can be freed right after the modular inverse). Those N freed temporaries will be needed again if another pooled modular inverse is required which is why prime95 won't let other threads reserve that memory. Build 3 did the exact same thing. What's different is the gwnum library in build 3 cached freed gwnums to make any future gwallocs fast. In build 4, only a handful of freed gwnums are cached making the remainder available for other threads and programs. This was done in hopes of helping nordi. I have some ideas for making future prime95's use memory a little better. There are pooling algorithms that use 3.33N multiplies and 1.5N temporaries OR 3.5N multiplies and 1.25N temporaries. I can check for the last pooled modular inverse and make the freed memory available for other threads. Last fiddled with by Prime95 on 2021-01-02 at 22:10 |
|
![]() |
![]() |
![]() |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Thinking of Joining GPU to 72 | jschwar313 | GPU to 72 | 3 | 2016-01-31 00:50 |
Thinking about lasieve5 | Batalov | Factoring | 6 | 2011-12-27 22:40 |
Thinking about buying a panda | jasong | jasong | 1 | 2008-11-11 09:43 |
Loud thinking on irregular primes | devarajkandadai | Math | 4 | 2007-07-25 03:01 |
Question on unfactored numbers... | WraithX | GMP-ECM | 1 | 2006-03-19 22:16 |