![]() |
[QUOTE=Batalov;129665]So, the 2304K FFT size (if it were effective) would have been really good for the now distributed 39.5-42M LL tests.[/QUOTE]
Probably. Prime95 only supports 5,6,7,8 times 2^n size FFT for two reasons. 1) It's assembly code, a pain to write and debug, limited interest and time, etc. 2) To write a 9*2^n FFT would need a code block that does FFT magic on 9 real values - however, there are only 8 registers. I fear that the extra work in shuffling data from registers would make the 9*2^n FFT as slow as the 5*2^(n+1) FFT - however I have no hard data to back up that fear. There is another alternative which has been on my wish list for a long, long time. All the big FFTs are done in two passes. The first pass does 5,6,7,or 8 * 2^x and the second pass does 2^y. It shouldn't be too difficult to also support a second pass that supports 3*2^y size. Combining the two would give us: 2^n, 3*2^n, 5*2^n, 7*2^n, 9*2^n, 15*2^n, 21*2^n |
[quote=Prime95;129695]It shouldn't be too difficult to also support a second pass that supports 3*2^y size. Combining the two would give us:
2^n, 3*2^n, 5*2^n, 7*2^n, 9*2^n, 15*2^n, 21*2^n[/quote] That would be fantastic. And what's really neat is that 25.x LL save files are not FFT, but the giant number, so when 25.7 is available one could just stop, replace the program, restart, and 2304K would pick-up the eligible exponents that were 2560K (if the binary would know to that it can do that; "2560" is also in the save file). [code] Prime95 32-bit version 25.6, RdtscTiming=1 ... Best time for 1280K FFT length: 33.617 ms. Best time for 1536K FFT length: 41.261 ms. Best time for 1792K FFT length: 49.368 ms. Best time for 2048K FFT length: 55.138 ms. [I]Best time for 2304K FFT length: 63.910 ms. (wishful thinking)[/I] Best time for 2560K FFT length: 72.682 ms. Best time for 3072K FFT length: 88.741 ms. [/code] |
[QUOTE=Batalov;129705] so when 25.7 is available one could just stop, replace the program, restart, and 2304K would pick-up[/QUOTE]
At no point in time did I say I was going to implement this. I can guarantee it won't happen this decade. |
mprime with threads: "Stop", "Exit" - results lost
In mprime on Linux/AMD: while doing P-1 tests:
when after "Test/Stop" ("4") one doesn't wait for a few seconds and presses "5" ("Test/Quit") - all is immediately killed and a couple of threads have their results lost. What's left is some "x" partial files, which shows that the threads were killed instantly after "Test/Quit". Solution: Please insert some wait() for threads in the code before quitting the main thread. |
[QUOTE=Batalov;129852]Solution: Please insert some wait() for threads in the code before quitting the main thread.[/QUOTE]
Will do. |
[quote=Prime95;129695]There is another alternative which has been on my wish list for a long, long time. All the big FFTs are done in two passes. The first pass does 5,6,7,or 8 * 2^x and the second pass does 2^y. It shouldn't be too difficult to also support a [U]second pass that supports 3*2^y size[/U]. Combining the two would give us:
2^n, 3*2^n, 5*2^n, 7*2^n, 9*2^n, 15*2^n, 21*2^n[/quote] 2304K. What a great number. 1536 squared. Its FFT's two passes would be symmetrical. The 10pfa6 pass1 code already exists. The 11-level pass2 code from 3M needs to be replaced by a code very similar to 10pfa6... I tried to dust off my assembly skills (left in the last century, literally) and I was reading the gwnum assembly code for a couple days now. I can see where in the jmptable the 2304K_011* branch could go. I can interpolate from the neighboring constants that the cutoff would be 44,300,000. Tortured xpass1sc.mac. But then I gave up as I moved into the xpass2.mac code... Even if I could foolishly put some hack together, I couldn't possibly debug. One needs a map of all registers, what where and when (or be born with it, or conversely having given birth to it - in the best sence of it). :bow: Please not the grand 9-15-21-solution right away? Just a 10pfa6-like in the second pass and 2304K FFT just for the enthusiastic testers? I personnally promise to test-run all the way through a dozen P-1s and a full LL for some exponent - in [I]both 2304K and 2560K[/I] and compare results if/when this code appears... [COLOR=#c0c0c0]Of course, some of the internal suitable by size 2560K existing stress tests could be simpy repeated in code as 2304K tests, as well, as the first line of bug defence, but I will commit to full-length tests... [/COLOR]I'll do so on both P95 and mprime or either, whatever you could possibly write in a brief break from the more important business. Is just 2304K alone still possible in this decade? Pleeeease? ...the wave is in the 39.5-44.3M range and it is going to take make so much sense, exactly now, not in the next decade. ______ :bow: "The words of the wise are as goads, and as nails fastened by THE MASTERS OF ASSEMBLIES..." (Ecclesiastes 12:11) |
Can't compile source
How does one compile mprime from source? I have downloaded the source256.zip and ran make in linux64 and got this output:
[code][ ! -e ../security.h ] && touch ../security.h || true [ ! -e ../security.c ] && touch ../security.c || true [ ! -e ../secure5.c ] && touch ../secure5.c || true gcc -I.. -I../gwnum -DX86_64 -O2 -c prime.c In file included from prime.c:102: ../primenet.c:1663:28: error: macro "v4_hash_packet" passed 2 arguments, but takes just 0 In file included from prime.c:102: ../primenet.c: In function ‘v4_format_args’: ../primenet.c:1663: error: ‘v4_hash_packet’ undeclared (first use in this function) ../primenet.c:1663: error: (Each undeclared identifier is reported only once ../primenet.c:1663: error: for each function it appears in.) ../primenet.c:1711:28: error: macro "v4_hash_packet" passed 2 arguments, but takes just 0 ../primenet.c:1806:28: error: macro "v4_hash_packet" passed 2 arguments, but takes just 0 ../primenet.c:1851:28: error: macro "v4_hash_packet" passed 2 arguments, but takes just 0 ../primenet.c:1930:28: error: macro "v4_hash_packet" passed 2 arguments, but takes just 0 ../primenet.c:1973:28: error: macro "v4_hash_packet" passed 2 arguments, but takes just 0 ../primenet.c:2014:28: error: macro "v4_hash_packet" passed 2 arguments, but takes just 0 make: *** [prime.o] Error 1[/code]The interesting part in primenet.c is here, starting at line 1521: [code]#include "security.c" #ifndef IPSHASH #define v4_hash_packet() #endif[/code]And then later there is code such as this on line 1663: [code]v4_hash_packet (0, &v4pkt);[/code]Which doesn't match the parameters of the macro, as the error shows. My security.[ch] and secure5.c files are blank. Is it not possible to compile the software from source without these? My compiler is gcc 4.1.2. |
change the #define to;
#define v4_hash_packet(a,b) |
Wow that was a fast reply! Thanks, I got it to compile now.
|
I just saw this happen:[code][Work thread Mar 30 10:24] Starting trial factoring of M487158697 to 2^59
[Work thread Mar 30 10:24] Trial factoring of M487158697 to 2^50 is 0.00% complete. [Work thread Mar 30 10:24] M487158697 has a factor: 66253582793 [Work thread Mar 30 10:24] M487158697 has a factor: 29275314737519[/code]I assume that finding multiple factors at once (36- and 45-bits in this case) like this is "normal" (if unusual)? |
Happens all the time for me in LMH.
|
| All times are UTC. The time now is 22:25. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.