|
[QUOTE=rebirther;523871][CODE]n:\riesel-base537 - Kopie>srsieve2 -n2501 -N10000 -P1e9 -spl_remain.txt -fB
srsieve2 v1.1, a program to find factors of k*b^n+c numbers for fixed b and vari able k and n Fatal Error: srsieve2: invalid argument -f B[/CODE][/QUOTE] That's because 'B' is missing from line 114 of SierpinskiRieselApp.cpp: [CODE]status = Parser::Parse(arg, "ADP", value);[/CODE] Is base 2 one of the slow bases for srsieve2? I tested 1467763*2^n-1, with n between 1.2e6 and 1.3e6, to P=1e9. srsieve took about [COLOR="Red"]141 seconds[/COLOR]. Here's the srsieve2 output: [QUOTE]srsieve2 v1.1, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Sieve started: 2 < p < 1e9 with 100001 terms (1200000 < n < 1300000, k*2^n+c) (expecting 96656 factors) Sieving with generic logic Sieving with generic logic p=868205083, 244.8K p/sec, 96449 factors found at 1.884 f/sec, 86.8% done. ETC 2019-08-30 22:02 Sieve completed at p=1000000009. Processor time: 207.48 sec. (0.64 sieving) (1.00 cores) 3534 terms written to b2_n.abcd Primes tested: 49847480. Factors found: 96467. Remaining terms: 3534. Time: [COLOR=red]208.32 seconds[/COLOR].[/QUOTE] Multiple threads did yield much better results. |
Also, in the same file, lines 528 and 530 should have newlines at the ends of the format strings. Right now, the first term is printed on the same line as the BOINC header.
|
[QUOTE=Happy5214;524883]That's because 'B' is missing from line 114 of SierpinskiRieselApp.cpp:
[CODE]status = Parser::Parse(arg, "ADP", value);[/CODE] Is base 2 one of the slow bases for srsieve2? I tested 1467763*2^n-1, with n between 1.2e6 and 1.3e6, to P=1e9. srsieve took about [COLOR="Red"]141 seconds[/COLOR].[/QUOTE] I'll add the missing 'B' and newlines I have no explanation at this time for the time difference between the two. I suspect is has to do with cache hits and misses because they use the same logic, albeit implemented slightly differently. srsieve2 uses vector<bool> while srsieve uses a bitmap. vector<bool> uses a byte per bit, so that could be the reason. I could play around with changing that to see the impact. BTW, here are the results on my lnew 6-core l7 laptop: [code] srsieve -n1200000 -N1300000 -P1e9 1467763*2^^n-1 srsieve 1.1.4 -- A sieve for integer sequences in n of the form k*b^n+c. srsieve started: 1200000 <= n <= 1300000, 3 <= p <= 1000000000 Split 1 base 2 sequence into 1 base 2^4 subsequence. p=557271703, 9296228 p/sec, 96371 terms eliminated, 3630 remain Sieving 3 <= p <= 1000000000 eliminated 96467 terms, 3534 remain. Wrote 3534 terms for 1 sequence to srsieve format file `srsieve.out'. srsieve stopped: at p=1000000000 because --pmax was reached. Processor time: [COLOR="Red"]104.00[/COLOR] sec srsieve2 -n1200000 -N1300000 -P1e9 -s1467763*2^^n-1 srsieve2 v1.1, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Sieve started: 2 < p < 1e9 with 100001 terms (1200000 < n < 1300000, k*2^n+c) (expecting 96656 factors) Sieving with generic logic Sieving with generic logic p=502635611, 419.7K p/sec, 96350 factors found at 1.612K f/sec, 50.3% done. ETC 2019-09-01 08:59 Sieve completed at p=1000000009. Processor time: 114.41 sec. (0.28 sieving) (0.98 cores) 3534 terms written to b2_n.abcd Primes tested: 49847480. Factors found: 96467. Remaining terms: 3534. Time: [COLOR="red"]116.21[/COLOR] seconds. [/code] It's still slower, but not by as much as your run. |
Could this be cache size differences? Does srsieve2 adjust for different size caches?
|
I'll admit that I have a really old machine (~10 years), so it has 4 MB of L2 and no L3. Caching could definitely be a factor.
As noted, using 2 or more threads on srsieve2 yields better results than srsieve, and that would be the intended use in my circumstance anyway (probably 3 threads on my non-exclusive quad-core). But srsieve2 is not even in the same country as sr1sieve (with Legendre), which is hovering around 50M p/sec at later p's. Hopefully, the upcoming improvements will close, or even reverse, the gap. On a side note, is there any particular reason why this code isn't in some sort of public VCS? |
I have a sourceforge repository, but haven't put the code into it. I'll do that soon.
srsieve2 does not have the functionality of sr1sieve or sr2sieve yet. I started implementing the logic from sr2sieve, but have been too busy. |
Is Happy5412's machine able to use the latest instructions srsieve2 is able to use(AVX?)? Could that be slowing it down?
|
[QUOTE=henryzz;525030]Is Happy5412's machine able to use the latest instructions srsieve2 is able to use(AVX?)? Could that be slowing it down?[/QUOTE]
There are no AVX instructions in srsieve2. I tried experimenting with AVX2 and got worse performance. This is due to a single loop which has a variable number of steps per prime. |
I have finally put mtsieve into [URL="https://sourceforge.net/projects/mtsieve/"]sourceforge[/URL]. Going forward, releases will be placed in sourceforge. I'll eventually update my webpage to point to sourceforge.
If anyone wants to contribute, please let me know and I can give you access to commit code changes. |
Thanks!
As an aside, why does everyone in this community love SVN so much? Every other coding community I'm part of uses Git or something similarly distributed. SVN just reminds me of a decade ago. |
[QUOTE=Happy5214;525319]Thanks!
As an aside, why does everyone in this community love SVN so much? Every other coding community I'm part of uses Git or something similarly distributed. SVN just reminds me of a decade ago.[/QUOTE] Having used both, svn is easier to use. git is better for projects with many contributors. |
Last version of mtsieve , error can be eliminated if -K is [B]odd [/B]number
[QUOTE]e:\MTSIEVE\mtsieve1957>twinsieve -P2000000000 -w10000000 -W4 -k10001 -K1000000 -b2 -n5333333 -o BASE2.txt -fA -r -s twinsieve v1.2, a program to find factors of k*b^n+1/-1 numbers for fixed b and n and variable k Sieve started: 1 < p < 2e9 with 990000 terms (10001 < k < 1000000, k*2^5333333) (expecting 957958 factors) Sieve completed at p=2000000011. Processor time: 10.06 sec. (0.80 sieving) (2.41 cores) [COLOR=Red][B]Fatal Error: Something is wrong. Counted terms (51638) != expected terms (51639)[/B][/COLOR][/QUOTE] |
[QUOTE=pepi37;525668]Last version of mtsieve , error can be eliminated if -K is [B]odd [/B]number[/QUOTE]
I'll take a look. Thanks. |
Last version of mtsieve , [B]gcwsieve[/B]
[QUOTE]gcwsieve -P 10000000 -w10000000 -W4 -O factors1.txt -b 196 -n 2 -N 800000 -s - [/QUOTE] So first problem - when I start this I cannot get more then 26% on quad core CPu so it use only little more then one core. [QUOTE]Processor time: 193.08 sec. (0.08 sieving) (0.98 cores)[/QUOTE]Second: if you tray to stop it it will write message [QUOTE]CTRL-C accepted. Please wait for threads to complete.[/QUOTE]but will not stop the program, program continues to run. If you second time type CTRL+c then programs end but [B]there is no output file.[/B] If you continue sieving with same parameters then GCWSIEVE will start to use 100% CPU |
[QUOTE=pepi37;526086]Last version of mtsieve , [B]gcwsieve[/B]
So first problem - when I start this I cannot get more then 26% on quad core CPu so it use only little more then one core. Second: if you tray to stop it it will write message but will not stop the program, program continues to run. If you second time type CTRL+c then programs end but [B]there is no output file.[/B] If you continue sieving with same parameters then GCWSIEVE will start to use 100% CPU[/QUOTE] This is likely because -w is so large. The problem is that gcwsieve will use a single thread until the first 10000000 primes are tested, which can take a while. I should be able to change it to break out of that first chunk earlier so that it can start using multiple threads more quickly. The other issue is that gcwsieve is a relatively slow sieve compared to srsieve2 and cksieve. It needs to finish the chunk of 10000000 primes before it terminates (when using ^C). I highly recommend setting -w to a lower value. |
[QUOTE=rogue;526120]This is likely because -w is so large. The problem is that gcwsieve will use a single thread until the first 10000000 primes are tested, which can take a while. [B][COLOR=Red]I should be able to change it to break out of that first chunk earlier so that it can start using multiple threads more quickly.[/COLOR][/B]
The other issue is that gcwsieve is a relatively slow sieve compared to srsieve2 and cksieve. It needs to finish the chunk of 10000000 primes before it terminates (when using ^C). I highly recommend setting -w to a lower value.[/QUOTE] If you can make that change I would like it. Thanks |
[QUOTE=pepi37;526144]If you can make that change I would like it.[/QUOTE]
I'll look into it. |
Hit error one more time, now on twinsieve
[QUOTE]e:\MTSIEVE\TWINSIEVE>twinsieve -P200000000000 -w10000000 -W4 -k3 -K2999999999 -b2 -n3344556 -o BASE2.txt --format=N twinsieve v1.2, a program to find factors of k*b^n+1/-1 numbers for fixed b and n and variable k Sieve started: 1 < p < 2e11 with 2999999997 terms (3 < k < 2999999999, k*2^3344556) (expecting 2920087813 factors) p=163019249773, 32.38M p/sec, 2996251067 factors found at 31.18K f/sec, 81.5% done. ETC 2019-09-21 13:36 Sieve completed at p=200000000041. Processor time: 1190.44 sec. (94.20 sieving) (2.55 cores) Fatal Error: Something is wrong. Counted terms (3687541) != expected terms (3690226)[/QUOTE] |
There is an error when compiling mtsieve from source. When it gets to compiling srsieve2, it stops here:
[CODE]sierpinski_riesel/SierpinskiRieselApp.cpp:20:10: fatal error: CIsOneSubsequenceHelper.h: No such file or directory #include "CIsOneSubsequenceHelper.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. makefile:118: recipe for target 'sierpinski_riesel/SierpinskiRieselApp.o' failed make: *** [sierpinski_riesel/SierpinskiRieselApp.o] Error 1[/CODE] which is expected since there is no file in the directory called "CIsOneSubsequenceHelper.h". But there exists a file called "CisOneSubsequenceHelper.h". Surely you meant to include that file instead? |
[QUOTE=rogue;524981]vector<bool> uses a byte per bit, so that could be the reason. I could play around with changing that to see the impact.
[/QUOTE] This is not true, vector<bool> is special, it may be implemented as a bit vector, see the documentation here: [url]https://en.cppreference.com/w/cpp/container/vector_bool[/url]. At least 5 years ago it was implemented as a bit vector in all available C++ compilers. The C++ community has not liked this (as this caused issues with iterating over the vector) and I remember that there have been discussions in the past about fixing this (by requiring vector<bool> to be implemented as a byte vector) but I don't know whether this has already been fixed. If you want a byte vector you should use vector<char>. |
Another thing: It appears the OpenCL executables are not working, regardless of whether I use the provided executables or if I compile from source. Case in point: on Windows:
[CODE]C:\Users\Dylan\Desktop\mtsieve\mtsieve>pixsievecl -h C:\Users\Dylan\Desktop\mtsieve\mtsieve>[/CODE]after executing the command the fan spins up for a second and then it quits without printing anything. This does not change regardless if the OpenCL library is installed or not. On Linux, using Google Colab, I used the following [CODE]import os.path from google.colab import drive if not os.path.exists('/content/drive/My Drive'): drive.mount('/content/drive') %cd '/content/drive/My Drive/mtsieve/mtsieve' #need gmp for some of the sieves !ls /usr/lib/x86_64-linux-gnu/ !apt-get install libgmp-dev ocl-icd-libopencl1 !make clean !make !./mfsievecl -W 2 -G 1 -P 2e13 -i factorial.pfgw -o factorial.pfgw[/CODE]and it compiled successfully after renaming the offending file. But when it goes to execute the program, it didn't start the sieve. |
[QUOTE=Dylan14;526255]There is an error when compiling mtsieve from source. When it gets to compiling srsieve2, it stops here:
[CODE]sierpinski_riesel/SierpinskiRieselApp.cpp:20:10: fatal error: CIsOneSubsequenceHelper.h: No such file or directory #include "CIsOneSubsequenceHelper.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. makefile:118: recipe for target 'sierpinski_riesel/SierpinskiRieselApp.o' failed make: *** [sierpinski_riesel/SierpinskiRieselApp.o] Error 1[/CODE] which is expected since there is no file in the directory called "CIsOneSubsequenceHelper.h". But there exists a file called "CisOneSubsequenceHelper.h". Surely you meant to include that file instead?[/QUOTE] Some OSes are case sensitive. Others are not. This is probably fixed in sourceforge. |
[QUOTE=Dylan14;526284]Another thing: It appears the OpenCL executables are not working, regardless of whether I use the provided executables or if I compile from source. Case in point: on Windows:
[CODE]C:\Users\Dylan\Desktop\mtsieve\mtsieve>pixsievecl -h C:\Users\Dylan\Desktop\mtsieve\mtsieve>[/CODE]after executing the command the fan spins up for a second and then it quits without printing anything. This does not change regardless if the OpenCL library is installed or not. On Linux, using Google Colab, I used the following [CODE]import os.path from google.colab import drive if not os.path.exists('/content/drive/My Drive'): drive.mount('/content/drive') %cd '/content/drive/My Drive/mtsieve/mtsieve' #need gmp for some of the sieves !ls /usr/lib/x86_64-linux-gnu/ !apt-get install libgmp-dev ocl-icd-libopencl1 !make clean !make !./mfsievecl -W 2 -G 1 -P 2e13 -i factorial.pfgw -o factorial.pfgw[/CODE]and it compiled successfully after renaming the offending file. But when it goes to execute the program, it didn't start the sieve.[/QUOTE] I'll look into the Windows build. I cannot speak for other OSes, but it could be the same problem. |
[QUOTE=rogue;526309]I'll look into the Windows build. I cannot speak for other OSes, but it could be the same problem.[/QUOTE]
Yes cl version on windows doesnot wok Just stop and crash |
One request fro gfndsieve
gfndsieve as output have pfgw file that is in fact ABCD file ( but not same as ABCD file produces as sr2sieve) And since gfndsieve is wayyyy faster then sr2sieve, can you add "normal" ABCD output as option , or you have some utility to convert it ? Your ABCD output ABCD $a*2^140000+1 [20023] // Sieved to 90076327351 252 36 66 "Normal ABCD "output ABCD 41067*2^$a+1 [130014] // Sieved to 1000000000 with srsieve 12 22 68 112 |
[QUOTE=pepi37;526326]One request fro gfndsieve
gfndsieve as output have pfgw file that is in fact ABCD file ( but not same as ABCD file produces as sr2sieve) And since gfndsieve is wayyyy faster then sr2sieve, can you add "normal" ABCD output as option , or you have some utility to convert it ? Your ABCD output ABCD $a*2^140000+1 [20023] // Sieved to 90076327351 252 36 66 "Normal ABCD "output ABCD 41067*2^$a+1 [130014] // Sieved to 1000000000 with srsieve 12 22 68 112[/QUOTE] Why do you need this functionality? |
[QUOTE=rogue;526330]Why do you need this functionality?[/QUOTE]
Because I need first to find primes, then it is easy to test it with PFGW. And LLR is faster then PFGW. |
[QUOTE=pepi37;526333]Because I need first to find primes, then it is easy to test it with PFGW.
And LLR is faster then PFGW.[/QUOTE] pfgw supports the format, but llr does not. Have you considered asking Jean to add support for that format? I don't know when I can get around to making that change. |
What's wrong with using srfile? I always use it to change from one format to the other, with -w or -G switches, etc. Also, a perl tool is just 3-4 lines (except including libs, or opening and closing files, etc).
|
[QUOTE=LaurV;526342]What's wrong with using srfile? I always use it to change from one format to the other, with -w or -G switches, etc. Also, a perl tool is just 3-4 lines (except including libs, or opening and closing files, etc).[/QUOTE]
e:\MTSIEVE\GFDN>sr gfnd.pfgw -k factors.txt -w srfile 1.1.3 -- A file utility for srsieve. ERROR: unrecognised file `gfnd.pfgw' e:\MTSIEVE\GFDN>sr gfnd.pfgw -k factors.txt -G srfile 1.1.3 -- A file utility for srsieve. ERROR: unrecognised file `gfnd.pfgw Also, does you have that perl script? I will be happy to run it. |
[QUOTE=rogue;526337]pfgw supports the format, but llr does not. Have you considered asking Jean to add support for that format? I don't know when I can get around to making that change.[/QUOTE]
But you wrote MTSIEVE, I am sure you can change it to "normal" ABCD if you wish. |
[QUOTE=pepi37;526326]
Your ABCD output ABCD $a*2^140000+1 [20023] // Sieved to 90076327351 252 36 66 "Normal ABCD "output ABCD 41067*2^$a+1 [130014] // Sieved to 1000000000 with srsieve 12 22 68 112[/QUOTE] The D in ABCD stands for "delta". i.e each value is a delta from the previous value. Are you looking for plain ABC (not ABCD) format where each line is an absolute value? |
[QUOTE=axn;526354]The D in ABCD stands for "delta". i.e each value is a delta from the previous value. Are you looking for plain ABC (not ABCD) format where each line is an absolute value?[/QUOTE]
I just need option that output is looking like "standard abcd", second sample in my post |
[QUOTE=pepi37;526348]But you wrote MTSIEVE, I am sure you can change it to "normal" ABCD if you wish.[/QUOTE]
[QUOTE=pepi37;526370]I just need option that output is looking like "standard abcd", second sample in my post[/QUOTE] There is no such thing as "normal" or "standard" ABCD format. ABC and ABC formats were developed by one of the original pfgw developers. IIRC, I helped Jean modify llr to support the ABC format. He later added one flavor of ABCD, but ABCD is much more than what llr is supporting. This is why I suggested that you reach out to Jean. It would make more sense for his software to support a bigger more "flavors" of ABCD. Yes, I could modify mtsieve to output an ABCD format that is supported by llr, but it isn't high on my priority list as it isn't a bug. As you can see in this thread there are bugs that are far more important to me to address. Unfortunately I have been busy, so I don't know when I'll have time to work on them. Note that all of the source is in sourceforge, so anyone that is familiar with C or C++ has a good shot of learning the code and making changes. |
[QUOTE=rogue;526373]There is no such thing as "normal" or "standard" ABCD format. .......[/QUOTE]
I know there is no such thing as standard abcd format: but you also limit with output format what program can or cannot be used. It is your decision: and on some previous suggestion you listen my wishes, and on some you will not . And it is OK, your time, your product, your path. I respect all that. And for part that all is on sourceforge and any can modify software, is a little cheeky explanation. I dont need to know how to write or modify program, so fact source code can be changed is useless for me.I know chemistry very well but I will not laugh because you don't know something, I try to explain to you. Best regards |
"Within the ABCD format, the difference on the first line is the [COLOR="Red"]insertion
of the [$a $b ...] information [/COLOR]from the first line of the ABC file, and on subsquent lines, only the [COLOR="Red"]delta of the accumulation[/COLOR] is written. In the ABCD format, blank lines are ignored, and it is valid to append ABCD files togther (or to have a siever output "headers" to switch processing)" What is the problem exactly? ABCD was designed for CPAP runs and to save on space. Why are you not using ABC format with the example headers? |
[QUOTE=paulunderwood;526389]"Within the ABCD format, the difference on the first line is the [COLOR="Red"]insertion
of the [$a $b ...] information [/COLOR]from the first line of the ABC file, and on subsquent lines, only the [COLOR="Red"]delta of the accumulation[/COLOR] is written. In the ABCD format, blank lines are ignored, and it is valid to append ABCD files togther (or to have a siever output "headers" to switch processing)" What is the problem exactly? ABCD was designed for CPAP runs and to save on space. Why are you not using ABC format with the example headers?[/QUOTE] The problem is that llr doesn't fully support ABCD. It only supports a subset of ABCD. pepi37 wants to use llr to test output from gfndsieve as llr is faster than pfgw for these candidates, but the ABCD format used by gfndsieve is not supported by llr. gfndsieve does not support other output formats at this time. If I owned the llr code base in addition to gfndsieve, then I would modify llr. That is why I suggest that he has Jean. |
[QUOTE=paulunderwood;526389]"Within the ABCD format, the difference on the first line is the [COLOR=Red]insertion
of the [$a $b ...] information [/COLOR]from the first line of the ABC file, and on subsquent lines, only the [COLOR=Red]delta of the accumulation[/COLOR] is written. In the ABCD format, blank lines are ignored, and it is valid to append ABCD files togther (or to have a siever output "headers" to switch processing)" What is the problem exactly? ABCD was designed for CPAP runs and to save on space. Why are you not using ABC format with the example headers?[/QUOTE] I play at home and try to find some xGF divisors. So I can make initial sieve by srsieve and sr2sieve but that was is much slower then gfdnsieve from MTsieve pack. Since I work with 1M or more candidates and even one test is about 4 seconds, different is huge when you have smaller number of candidate . And gfndsieve give me that with speed. But output ( at least to me) cannot be used on other program then PFGW, and I use Prime95 to find PRP and then it is easy with PFGW to test is prime xGF or not. |
@rogue:
a feature request for srsieve2, the x factors found is uninteresting for me, can you replace it with x factors left + factors found rate f/sec? The factors left total I can only see at the end of sieving. |
[QUOTE=pepi37;526418]I play at home and try to find some xGF divisors. So I can make initial sieve by srsieve and sr2sieve but that was is much slower then gfdnsieve from MTsieve pack.
Since I work with 1M or more candidates and even one test is about 4 seconds, different is huge when you have smaller number of candidate . And gfndsieve give me that with speed. But output ( at least to me) cannot be used on other program then PFGW, and I use Prime95 to find PRP and then it is easy with PFGW to test is prime xGF or not.[/QUOTE] Can you run Perl? I am sure someone will knock up a program to convert from ABCD to Prime95 format... |
[QUOTE=paulunderwood;526426]Can you run Perl? I am sure someone will knock up a program to convert from ABCD to Prime95 format...[/QUOTE]
I will install it if someone give me Perl code |
Put this in a file called [C]abcd2p95.pl[/C] and run it like [C]perl abcd2p95.pl file.ABCD prime95input.txt[/C].
Make sure you do a backup of the sieve file first in case something goes wrong. [CODE]open INFILE, "<@ARGV[0]" or die "Need input file\n"; open OUTFILE, ">@ARGV[1]" or die "Need output file\n"; @header = split( ' ', <INFILE> ); @expression = split( '\$', @header[1] ); @start = split( '\[', @header[2] ); @start = split( '\]', @start[1] ); $current = @start[0]; print OUTFILE $expression[0].$current.substr($expression[1],1)."\n"; while ( <INFILE> ) { $current += $_; print OUTFILE $expression[0].$current.substr($expression[1],1)."\n"; } [/CODE] |
Script is working but output file is wrong.
I have search in range k=20000 to 29999 and n=140000 to 150000 this is few factors to understand [QUOTE]90109718183 | 25809*2^146911+1 90084905843 | 28401*2^144193+1 90110967913 | 21673*2^140160+1 90110995423 | 27213*2^145845+1 90086036939 | 29667*2^147152+1 90086094547 | 29673*2^142642+1 90111537401 | 21821*2^145953+1 90137001109 | 22923*2^145704+1 90086812721 | 26817*2^143047+1[/QUOTE] your script as output give me this (last few results) [QUOTE]99201471*2^140000+1 99201501*2^140000+1 99201525*2^140000+1 99201531*2^140000+1 99201551*2^140000+1 99201555*2^140000+1 99201585*2^140000+1 99201597*2^140000+1 99201681*2^140000+1 99201735*2^140000+1 99201765*2^140000+1 99201797*2^140000+1[/QUOTE] So n is fixed to 140000 ( that is first problem) and second that k is out of range. |
I have modified the above script to print to file the very first value in "[...]".
What you have there is a factor file, not an [U]ABCD[/U] file. Here is my run of [C]perl ABCD2P95.pl test.ABCD test.p95input[/C] test.ABCD: [CODE]ABCD $a*2^140000+1 [20023] // Sieved to 97478600873 252 36 66 36 44 4 2 54 24 36 10 20 54[/CODE] test.p95input [CODE]20023*2^140000+1 20275*2^140000+1 20311*2^140000+1 20377*2^140000+1 20413*2^140000+1 20457*2^140000+1 20461*2^140000+1 20463*2^140000+1 20517*2^140000+1 20541*2^140000+1 20577*2^140000+1 20587*2^140000+1 20607*2^140000+1 20661*2^140000+1 [/CODE] |
[QUOTE=paulunderwood;526471]I have modified the above script to print to file the very first value in "[...]".
What you have there is a factor file, not an [U]ABCD[/U] file. Here is my run of [C]perl ABCD2P95.pl test.ABCD test.p95input[/C] test.ABCD: [CODE]ABCD $a*2^140000+1 [20023] // Sieved to 97478600873 252 36 66 36 44 4 2 54 24 36 10 20 54[/CODE] test.p95input [CODE]20275*2^140000+1 20311*2^140000+1 20377*2^140000+1 20413*2^140000+1 20457*2^140000+1 20461*2^140000+1 20463*2^140000+1 20517*2^140000+1 20541*2^140000+1 20577*2^140000+1 20587*2^140000+1 20607*2^140000+1 20661*2^140000+1 [/CODE][/QUOTE] Where is New perl code? |
[QUOTE=pepi37;526472]Where is New perl code?[/QUOTE]
[url]https://mersenneforum.org/showpost.php?p=526436&postcount=236[/url] (Note 20023 will be included!) |
[QUOTE=paulunderwood;526474][URL]https://mersenneforum.org/showpost.php?p=526436&postcount=236[/URL]
(Note 20023 will be included!)[/QUOTE] As I say before , I search in range k= 20000 to 29999 n=140000 to 150000 Part of output of perl script k is above my limit n is fixed to 140000 and that is no true [QUOTE]196749*2^140000+1 196775*2^140000+1 196785*2^140000+1 196815*2^140000+1 196865*2^140000+1 [/QUOTE] |
Here is the script that handles multiple header lines in a file:
[CODE]open INFILE, "<@ARGV[0]" or die "Need input file\n"; open OUTFILE, ">@ARGV[1]" or die "Need output file\n"; while ( <INFILE> ) { if( $_ =~ /\[/ ) { @header = split( ' ', $_ ); @expression = split( '\$', @header[1] ); @start = split( '\[', @header[2] ); @start = split( '\]', @start[1] ); $current = @start[0]; } else { $current += $_; } print OUTFILE $expression[0].$current.substr($expression[1],1)."\n"; } [/CODE] |
[QUOTE=paulunderwood;526476]Here is the script that handles multiple header lines in a file:
[CODE]open INFILE, "<@ARGV[0]" or die "Need input file\n"; open OUTFILE, ">@ARGV[1]" or die "Need output file\n"; while ( <INFILE> ) { if( $_ =~ /\[/ ) { @header = split( ' ', $_ ); @expression = split( '\$', @header[1] ); @start = split( '\[', @header[2] ); @start = split( '\]', @start[1] ); $current = @start[0]; } else { $current += $_; } print OUTFILE $expression[0].$current.substr($expression[1],1)."\n"; } [/CODE][/QUOTE] THANKS, works perfect! |
[QUOTE=rebirther;526420]@rogue:
a feature request for srsieve2, the x factors found is uninteresting for me, can you replace it with x factors left + factors found rate f/sec? The factors left total I can only see at the end of sieving.[/QUOTE] I'll think about it. It would likely need another switch to control what to show, i.e. factors found or remaining terms. |
[QUOTE=rogue;526486]I'll think about it. It would likely need another switch to control what to show, i.e. factors found or remaining terms.[/QUOTE]
And to spend time the prp output file. |
[QUOTE=rebirther;526499]And to spend time the prp output file.[/QUOTE]
I believe I added that in the latest build. Try -fB. I call it BOINC format since it is used for input to BOINC. |
[QUOTE=rogue;526501]I believe I added that in the latest build. Try -fB. I call it BOINC format since it is used for input to BOINC.[/QUOTE]
nope, still not working |
[QUOTE=rebirther;526512]nope, still not working[/QUOTE]
In what way is it not working? is this the missing carriage return or something else? |
[QUOTE=rogue;526514]In what way is it not working? is this the missing carriage return or something else?[/QUOTE]
Fatal error: invalid argument |
[QUOTE=rebirther;526547]Fatal error: invalid argument[/QUOTE]
See [URL]https://www.mersenneforum.org/showpost.php?p=524883&postcount=195[/URL]. SVN hasn't been updated yet to add this fix. |
Sorry, but I have been busy and haven't had time to make changes.
|
[QUOTE=pepi37;526221]Hit error one more time, now on twinsieve[/QUOTE]
I haven't been able to reproduce this yet. It might be fixed with some other changes I've made to the framework, but I don't know right now. I need to continue testing. |
I did find a bug that can occur when using multiple threads. I suspect that might be behind the error you encountered.
|
I have committed a number of code changes to sourceforge to address the reported issues. The changes are not fully tested, but I think the reported issues are fixed. I haven't updated the distribution yet. I will do that as soon as I can.
|
I tracked down the memory leak in srsieve2. It was caused by an overloaded operator that was using a copy constructor.
|
I am interested in low weight numbers of the form k*b^n+-1 with fixed k and b and variable n. (srsieve2.exe)
Is it possible to add support for large bases where b'=b^x and large k values where k'=k*b^y where b is small <100 and b' is greater than 2^64 Currently the program does not automatically convert k*b^n+-1 to k'*b'^n+-1 to increase speed. Thanks. |
[QUOTE=Citrix;529034]I am interested in low weight numbers of the form k*b^n+-1 with fixed k and b and variable n. (srsieve2.exe)
Is it possible to add support for large bases where b'=b^x and large k values where k'=k*b^y where b is small <100 and b' is greater than 2^64 Currently the program does not automatically convert k*b^n+-1 to k'*b'^n+-1 to increase speed. Thanks.[/QUOTE] If I understand correctly, you want k*b^y*(b^x)^n+-1. Since this is k*b^(y+x*n)+-1, as long as k < 2^63, you can start with srsieve2, but then use a scripting language to eliminate all candidates that you don't fit. Could also also generate your input candidate file then start sieving from p=3. Am I missing something? |
[QUOTE=rogue;529050]If I understand correctly, you want k*b^y*(b^x)^n+-1.
Am I missing something?[/QUOTE] Yes this is correct. For a range of n=1 to 1000000 the discrete log would have 1000 BS and 1000 GS If we know x =16 Then the range becomes n=1 to 62500 (for base b^16) and the discrete log would have 250 BS and 250 GS 4 times faster. For extremely low weights (that I am working with) where x can be close to 10000 the program can be made significantly faster. (~100 times) Currently the program does not automatically detect the pattern and calculate the value of x. (To calculate x you just need the gcd of the difference of all the consecutive candidates left in the sieve. You can do this just once at the start of the sieve). Thanks. |
[QUOTE=Citrix;529059]Yes this is correct.
For a range of n=1 to 1000000 the discrete log would have 1000 BS and 1000 GS If we know x =16 Then the range becomes n=1 to 62500 (for base b^16) and the discrete log would have 250 BS and 250 GS 4 times faster. For extremely low weights (that I am working with) where x can be close to 10000 the program can be made significantly faster. (~100 times) Currently the program does not automatically detect the pattern and calculate the value of x. (To calculate x you just need the gcd of the difference of all the consecutive candidates left in the sieve. You can do this just once at the start of the sieve). Thanks.[/QUOTE] The old srxsieve programs will cope with that as they will sieve sub-sequences when only a few remain. This results in a huge speedup for low weight sequences. This is a feature than mtsieve should have if it doesn't already(I haven't used the srsieve2 yet so I don't know) |
[QUOTE=henryzz;529070]The old srxsieve programs will cope with that as they will sieve sub-sequences when only a few remain. This results in a huge speedup for low weight sequences. This is a feature than mtsieve should have if it doesn't already(I haven't used the srsieve2 yet so I don't know)[/QUOTE]
Srxsieve also misses this at times. As it only looks at x=factors of 720. |
Twinsieve and CPU utilization
As you know I do many jobs with your twinsieve. Since I buy new 6 core CPU I noticed something I was not sow on 4 core CPU.
If I run sieve from start somewhere up to 2e15 I can get nearly 96% of CPU usage on 6 core CPU . But if I run it from 2e16 to 4e16 then I cannot get more then 45% of CPU usage. I can increase "W" option and can get around 62% of CPU usage but that is all I can get. I assume on higher sieve depth CPU do less job since there is smaller number of primes to test, but how to get at least 90% of CPU usage on those, higher sieve depth? I try to increase worker number from 6 to 8 but that doesnot help. Any other suggestion? |
[QUOTE=pepi37;532683]As you know I do many jobs with your twinsieve. Since I buy new 6 core CPU I noticed something I was not sow on 4 core CPU.
If I run sieve from start somewhere up to 2e15 I can get nearly 96% of CPU usage on 6 core CPU . But if I run it from 2e16 to 4e16 then I cannot get more then 45% of CPU usage. I can increase "W" option and can get around 62% of CPU usage but that is all I can get. I assume on higher sieve depth CPU do less job since there is smaller number of primes to test, but how to get at least 90% of CPU usage on those, higher sieve depth? I try to increase worker number from 6 to 8 but that doesnot help. Any other suggestion?[/QUOTE] I'm guessing the bottleneck is where it gets the next block of primes for testing as only one thread can get a block of primes at a time. I don't have any great ideas as to how to address that right now. One option would be to run two instances across two different ranges of primes, saving the factors (-O) then using -I to remove terms from the original input file. |
@rogue: Is there any progress for the srsieve2 prp output format. I could really need it.
|
[QUOTE=rebirther;534949]@rogue: Is there any progress for the srsieve2 prp output format. I could really need it.[/QUOTE]
(going off of memory here) I think this is the -fB option. Can you verify that it exists in the latest released version and if it does, if that is what you are looking for? |
[QUOTE=rogue;534968](going off of memory here) I think this is the -fB option. Can you verify that it exists in the latest released version and if it does, if that is what you are looking for?[/QUOTE]
yes -fB and no its not working |
[QUOTE=rebirther;534969]yes -fB and no its not working[/QUOTE]
What do you mean by "not working"? Please be more specific. |
[QUOTE=rogue;535000]What do you mean by "not working"? Please be more specific.[/QUOTE]
If it's the same issue as before, I posted a fix at [URL]https://www.mersenneforum.org/showpost.php?p=524883&postcount=195[/URL]. It wasn't in SVN last time I checked. |
[QUOTE=Happy5214;535016]If it's the same issue as before, I posted a fix at [URL]https://www.mersenneforum.org/showpost.php?p=524883&postcount=195[/URL]. It wasn't in SVN last time I checked.[/QUOTE]
I might have committed the source, but not posted a new build. I'll take a look as soon as I have a chance. |
[QUOTE=rogue;535029]I might have committed the source, but not posted a new build. I'll take a look as soon as I have a chance.[/QUOTE]
I have uploaded 1.9.6 to sourceforge. 1.9.5 is still available as I didn't have enough time to test the change in 1.9.6. [LIST][*]Refactored logic for "single worker" and "rebuild" logic so they work more nicely together.[*]Fixed calculation of p/sec which is wrong after workers are recreated.[*]Reset factor stats whenever workers are created as the rate is inflated for lower p as far more terms are removed.[*]Fix issue with multiple threads which can cause program to hang.[*]Add support for ABC format to srsieve2.[/LIST] srsieve now supports ABNP options for the file format. If they don't work as desired, please let me know. Option B is the one that generates a newpgen like header for BOINC. I think that ABC is the PRP format that you are looking for, but as I stated above, I haven't had time to test. I had made these changes months ago. |
Thx rogue, still not working:
output: [CODE]n:\sierp-base267>srsieve2 -n2501 -N10000 -P1e9 -spl_remain.txt -fB srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and vari able k and n Sieving with generic logic n:\sierp-base267>pause[/CODE] after trying to sieve the file it will abort all the time without an error. |
[QUOTE=rebirther;535110]Thx rogue, still not working:
output: [CODE]n:\sierp-base267>srsieve2 -n2501 -N10000 -P1e9 -spl_remain.txt -fB srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and vari able k and n Sieving with generic logic n:\sierp-base267>pause[/CODE] after trying to sieve the file it will abort all the time without an error.[/QUOTE] Hmm. Please PM me your pl_remain.txt file. |
I'm getting a segfault with srsieve2 from SVN:
[CODE]$ ./srsieve2 -W 3 -n 1 -N 1500000 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Segmentation fault (core dumped)[/CODE] Generally, I have consistently been having issues with n ranges starting with 1. |
[QUOTE=Happy5214;535152]I'm getting a segfault with srsieve2 from SVN:
[CODE]$ ./srsieve2 -W 3 -n 1 -N 1500000 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Segmentation fault (core dumped)[/CODE] Generally, I have consistently been having issues with n ranges starting with 1.[/QUOTE] Both mtsieve 1.9.5 and 1.9.6 or just 1.9.6? |
[QUOTE=rebirther;535110]Thx rogue, still not working:
output: [CODE]n:\sierp-base267>srsieve2 -n2501 -N10000 -P1e9 -spl_remain.txt -fB srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and vari able k and n Sieving with generic logic n:\sierp-base267>pause[/CODE] after trying to sieve the file it will abort all the time without an error.[/QUOTE] Stupid error on my part. It will be fixed and posted later today. |
[QUOTE=Happy5214;535152]I'm getting a segfault with srsieve2 from SVN:
[CODE]$ ./srsieve2 -W 3 -n 1 -N 1500000 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Segmentation fault (core dumped)[/CODE] Generally, I have consistently been having issues with n ranges starting with 1.[/QUOTE] The segfault is the same issue. I'm not certain why one just terminates without a segfault and the other does. For this range I now see this: [code] srsieve2 -W 3 -n 100 -N 1500000 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Sieve started: 2 < p < 1e9 with 1499901 terms (100 < n < 1500000, k*2^n+c) (expecting 1449733 factors) Sieving with generic logic Split 1 base 2 sequence into 1 base 2^120 sequences. Fatal Error: 963643*2^14263-1 mod 269 = 142 [/code] I don't know what is causing that yet. Fortunately you can break it up into smaller ranges: [code] srsieve2 -W 3 -n 1 -N 200 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Sieve started: 2 < p < 1e9 with 200 terms (1 < n < 200, k*2^n+c) (expecting 193 factors) Sequence 963643*2^n-1 removed as all terms have a factor Fatal Error: All sequences have been removed srsieve2 -W 3 -n 200 -N 5000 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Sieve started: 2 < p < 1e9 with 4801 terms (200 < n < 5000, k*2^n+c) (expecting 4640 factors) Sieving with generic logic Split 1 base 2 sequence into 1 base 2^24 sequences. Sieving with generic logic Split 1 base 2 sequence into 1 base 2^24 sequences. CTRL-C accepted. Please wait for threads to complete. Sieve interrupted at p=694848779. Processor time: 21.72 sec. (0.39 sieving) (2.82 cores) 8 terms written to t17_b2.prp Primes tested: 33000000. Factors found: 0. Remaining terms: 8. Time: 7.69 seconds. [/code] and eventually test the entire range. That is just a workaround. I still need to find the root cause of this issue and fix it. |
I found the cause of the other issue. That will be fixed in the next update as well.
|
[QUOTE=rogue;535165]The segfault is the same issue. I'm not certain why one just terminates without a segfault and the other does. For this range I now see this:
[code] srsieve2 -W 3 -n 100 -N 1500000 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Sieve started: 2 < p < 1e9 with 1499901 terms (100 < n < 1500000, k*2^n+c) (expecting 1449733 factors) Sieving with generic logic Split 1 base 2 sequence into 1 base 2^120 sequences. Fatal Error: 963643*2^14263-1 mod 269 = 142 [/code]I don't know what is causing that yet. Fortunately you can break it up into smaller ranges: [code] srsieve2 -W 3 -n 1 -N 200 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Sieve started: 2 < p < 1e9 with 200 terms (1 < n < 200, k*2^n+c) (expecting 193 factors) Sequence 963643*2^n-1 removed as all terms have a factor Fatal Error: All sequences have been removed srsieve2 -W 3 -n 200 -N 5000 -P 1e9 -o t17_b2.prp -f B -s "963643*2^n-1" srsieve2 v1.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Sieving with generic logic Sieve started: 2 < p < 1e9 with 4801 terms (200 < n < 5000, k*2^n+c) (expecting 4640 factors) Sieving with generic logic Split 1 base 2 sequence into 1 base 2^24 sequences. Sieving with generic logic Split 1 base 2 sequence into 1 base 2^24 sequences. CTRL-C accepted. Please wait for threads to complete. Sieve interrupted at p=694848779. Processor time: 21.72 sec. (0.39 sieving) (2.82 cores) 8 terms written to t17_b2.prp Primes tested: 33000000. Factors found: 0. Remaining terms: 8. Time: 7.69 seconds. [/code]and eventually test the entire range. That is just a workaround. I still need to find the root cause of this issue and fix it.[/QUOTE] I still use sr1sieve (sr2sieve for multi-k batches) past p=1e9, so I just went ahead and used the old srsieve instead. I've also hit this issue with other low ranges, though I don't have a record of what those batches were. The segfault was new in the SVN version. My copy of 1.9.5 (from source) did display a divisibility check error similar to the first quoted output. |
[QUOTE=Happy5214;535174]I still use sr1sieve (sr2sieve for multi-k batches) past p=1e9, so I just went ahead and used the old srsieve instead. I've also hit this issue with other low ranges, though I don't have a record of what those batches were.
The segfault was new in the SVN version. My copy of 1.9.5 (from source) did display a divisibility check error similar to the first quoted output.[/QUOTE] Yup, that is what I have fixed. The issue is a piece of code that computes b^n (mod p) which only works if n > 0. In this case n = 0, so it failed. Eventually srsieve2 will be able to do what sr1sieve does, but I need to finish the integration of sr2sieve logic. It is partially there, but disabled. I just haven't had time to do it. |
I have posted 1.9.7 and removed 1.9.6. The only change is to fix the two bugs in srsieve2.
|
Got a permanent error while trying to use srsieve2:
[CODE] $ ./srsieve2 -P1000000000 -n2 -N10000 -fA -s"64*500^n+1" srsieve2 v1.2.1, a program to find factors of k*b^n+c numbers for fixed b and variable k and n (kp) Sequence has algebraic factorization: 64*500^n+1 -> (4^3)*500^n+1 (kp) Sequence 64*500^n+1 has 3333 terms removed due to algebraic factors of the form 4*500^(n/3)+1 (cr) Sequence has algebraic factorization: 64*500^n+1 -> 64*500^6 = (2^2*5^2)^9 (cr) Sequence has algebraic factorization: 64*500^n+1 -> 64*500^6 = (2^3*5^3)^6 (cr) Sequence has algebraic factorization: 64*500^n+1 -> 64*500^6 = (2^6*5^6)^3 (cr) Sequence has algebraic factorization: 64*500^n+1 -> 64*500^6 = (2^9*5^9)^2 (p4) Removed 1667 algebraic factors for 64*500^n+1 of the form (2*2^2*500^(n/2)+2*2^1*500^(n/4)+1) Sieving with generic logic Sieve started: 2 < p < 1e9 with 4999 terms (2 < n < 10000, k*500^n+c) (expecting 4832 factors) Unable to lock mutex thread_1_worker. Exiting. [/CODE] |
[QUOTE=unconnected;535325]Got a permanent error while trying to use srsieve2:
[CODE] $ ./srsieve2 -P1000000000 -n2 -N10000 -fA -s"64*500^n+1" srsieve2 v1.2.1, a program to find factors of k*b^n+c numbers for fixed b and variable k and n (kp) Sequence has algebraic factorization: 64*500^n+1 -> (4^3)*500^n+1 (kp) Sequence 64*500^n+1 has 3333 terms removed due to algebraic factors of the form 4*500^(n/3)+1 (cr) Sequence has algebraic factorization: 64*500^n+1 -> 64*500^6 = (2^2*5^2)^9 (cr) Sequence has algebraic factorization: 64*500^n+1 -> 64*500^6 = (2^3*5^3)^6 (cr) Sequence has algebraic factorization: 64*500^n+1 -> 64*500^6 = (2^6*5^6)^3 (cr) Sequence has algebraic factorization: 64*500^n+1 -> 64*500^6 = (2^9*5^9)^2 (p4) Removed 1667 algebraic factors for 64*500^n+1 of the form (2*2^2*500^(n/2)+2*2^1*500^(n/4)+1) Sieving with generic logic Sieve started: 2 < p < 1e9 with 4999 terms (2 < n < 10000, k*500^n+c) (expecting 4832 factors) Unable to lock mutex thread_1_worker. Exiting. [/CODE][/QUOTE] Hmm. I cannot reproduce this on Windows. I'll try on my Mac later. |
I'm on Ubuntu 18.04.3 LTS, kernel version 5.3.7.
srsieve2 binary info: [CODE]$ file srsieve2 srsieve2: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=b0d4a87145925df566d084383d36b5997f8faf0a, not stripped $ ldd srsieve2 linux-vdso.so.1 (0x00007fff35128000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4346d2c000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f43469a3000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4346605000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f43463ed000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4345ffc000) /lib64/ld-linux-x86-64.so.2 (0x00007f4347180000) [/CODE] Things I've tried - varyed sequences and sieve ranges, set -W option, even run from root account - none of this helped. Let me know if you need any additional info to investigate this issue. My initial goal was to integrate srsieve2 to srbsieve to speed up overall progress. |
Since you are building on your own, you can comment out the code in the SharedMemoryItem.cpp class in the TryLock(), Lock(), and Release() methods and rebuild. This will only work if you have 1 worker.
If you have any debugging experience, a stack trace would be helpful. |
[QUOTE=rogue;535217]I have posted 1.9.7 and removed 1.9.6. The only change is to fix the two bugs in srsieve2.[/QUOTE]
Link is outdated. Give me 1.9.5.7 version |
@rogue: Just let you know that the -fB switch is working now :)
|
[QUOTE=pepi37;535387]Link is outdated. Give me 1.9.5.7 version[/QUOTE]
There is no 1.9.5.7. There is 1.9.5 and 1.9.7. Since you are not on Windows, you need to d/l 1.9.7 and build. All of the source is checked in (I think) and is included in the .7z file (by accident). |
[QUOTE=rogue;535354]Since you are building on your own, you can comment out the code in the SharedMemoryItem.cpp class in the TryLock(), Lock(), and Release() methods and rebuild. This will only work if you have 1 worker.
If you have any debugging experience, a stack trace would be helpful.[/QUOTE] Mark, I've added debug printf to Lock() and found that in case of error return code is 35 (EDEADLK): [CODE]The pthread_mutex_lock() function may fail if: EDEADLK The current thread already owns the mutex. [/CODE]Commenting methods didn't help - source successfully compiled and ran but no sieve at all, only removed algebraic factors. |
[QUOTE=unconnected;535571]Mark, I've added debug printf to Lock() and found that in case of error return code is 35 (EDEADLK):
[CODE]The pthread_mutex_lock() function may fail if: EDEADLK The current thread already owns the mutex. [/CODE]Commenting methods didn't help - source successfully compiled and ran but no sieve at all, only removed algebraic factors.[/QUOTE] The offending code appears to be core/Worker.cpp, lines 164-167: [code] SetHasWorkToDo(); // ip_WorkerStatus->Release();[/code] The lock is being released [I]after[/I] the worker status is changed, so the first method ends up re-locking the mutex. Flipping the two commands fixed the error for me. |
[QUOTE=Happy5214;535574]The offending code appears to be core/Worker.cpp, lines 164-167:
[code] SetHasWorkToDo(); // ip_WorkerStatus->Release();[/code] The lock is being released [I]after[/I] the worker status is changed, so the first method ends up re-locking the mutex. Flipping the two commands fixed the error for me.[/QUOTE] Great catch, but the proper fix is to modify Worker.h. SetHasWorkToDo() should call ip_WorkerStatus->SetValueHaveLock(). This is because the method is called when the thread already has a lock on the ip_WorkerStatus object. This method releases that lock after it has built the collection of primes for the thread. I wonder why Windows doesn't catch this. |
[QUOTE=rogue;535619]Great catch, but the proper fix is to modify Worker.h. SetHasWorkToDo() should call ip_WorkerStatus->SetValueHaveLock(). This is because the method is called when the thread already has a lock on the ip_WorkerStatus object. This method releases that lock after it has built the collection of primes for the thread.
I wonder why Windows doesn't catch this.[/QUOTE] From the [URL="https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entercriticalsection"]Microsoft documentation on EnterCriticalSection[/URL]: [QUOTE]After a thread has ownership of a critical section, it can make additional calls to [B]EnterCriticalSection[/B] or [URL="https://docs.microsoft.com/windows/desktop/api/synchapi/nf-synchapi-tryentercriticalsection"]TryEnterCriticalSection[/URL] without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. The thread enters the critical section each time [B]EnterCriticalSection[/B] and [B]TryEnterCriticalSection[/B] succeed. A thread must call [URL="https://docs.microsoft.com/windows/desktop/api/synchapi/nf-synchapi-leavecriticalsection"]LeaveCriticalSection[/URL] once for each time that it entered the critical section.[/QUOTE]I take this to mean that repeated calls don't result in an error, unlike pthreads. |
[QUOTE=Happy5214;535629]From the [URL="https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entercriticalsection"]Microsoft documentation on EnterCriticalSection[/URL]:
I take this to mean that repeated calls don't result in an error, unlike pthreads.[/QUOTE] :censored: Yet another reason to dislike Windows. Thanks for finding the reason. |
| All times are UTC. The time now is 01:32. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.