I tried your file.
I have to copy the CL folder to mtsieve for it to compile.
gcwsievecl still crashes.

[QUOTE=Citrix;548746]I tried your file.
I have to copy the CL folder to mtsieve for it to compile.
gcwsievecl still crashes.[/QUOTE]

Let's continue via PM or e-mail.

[QUOTE=rebirther;548682]The split line was missing and only 2 workers of 16 are running, tried several times with the same result.[/QUOTE]

Please explain what you mean by "same result".

[QUOTE=rogue;548757]Let's continue via PM or e-mail.[/QUOTE]

I downloaded the latest version of mtsieve and compiled it. gcwsievecl.exe does work and did not crash. :smile:

The cl code is not working properly. I will play with it and let you know.

The make file for version 1.94 is not properly configured for GPU compiling.

[QUOTE=rogue;548758]Please explain what you mean by "same result".[/QUOTE]

same issue

[QUOTE=rebirther;548767]same issue[/QUOTE]

With the latest from sourceforge (2.0.3), I don't see this behavior. After it "splits" I can see that mutliple threads are running due to CPU utilization in Task Manager.

[QUOTE=Citrix;548765]I downloaded the latest version of mtsieve and compiled it. gcwsievecl.exe does work and did not crash. :smile:

The cl code is not working properly. I will play with it and let you know.

The make file for version 1.94 is not properly configured for GPU compiling.[/QUOTE]

Great to hear. Yes, you should use the current version of the makefile, even with 1.9.4.

Originally I had only one exe, which works for most people even if they didn't or couldn't use the GPU code, but some had issues because at runtime it would look for GPU related libraries even if they were not using GPU workers.

For example, there is now App_cpu.o and App_gpu.o. App.cpp is used to build both, but a compiler switch will build different objects.

[QUOTE=rogue;548793]With the latest from sourceforge (2.0.3), I don't see this behavior. After it "splits" I can see that mutliple threads are running due to CPU utilization in Task Manager.[/QUOTE]


base S652 was running on all cores with -W16 but S913 did not (Ryzen 3950X) -->latest 2.0.3

[QUOTE=rebirther;548812]base S652 was running on all cores with -W16 but S913 did not (Ryzen 3950X) -->latest 2.0.3[/QUOTE]

Did you do both of these on the same machine?

For S913, it needs to reach a certain sieving depth before switching to multiple cores. I wonder if didn't get to that sieving depth or if it thought it needed to sieve deeper for S913 than S652 before switching. Can you post the pl_remain.txt files for both bases?

[QUOTE=rogue;548814]Did you do both of these on the same machine?

For S913, it needs to reach a certain sieving depth before switching to multiple cores. I wonder if didn't get to that sieving depth or if it thought it needed to sieve deeper for S913 than S652 before switching. Can you post the pl_remain.txt files for both bases?[/QUOTE]


yes, both files attached

[QUOTE=rebirther;548939]yes, both files attached[/QUOTE]

If my memory serves me right, when playing around with srsieve2, for curiosity only, I had to make a value of -w 10000000 (1e7), before srsieve2 used all 4 cores when sieving SR3 (for thousands of k's and very low p value). It also appeared, testing with sr383 sieve file, that for utilisation of ALL cores, one has to use a higher -w value than what is set as default - at least if one want's to use full ressources of ones machine.

[QUOTE=rebirther;548812]base S652 was running on all cores with -W16 but S913 did not (Ryzen 3950X) -->latest 2.0.3[/QUOTE]

I found the cause. I'll try to get it fixed later today. The main issue is that it will slow down sieving for p > base. To work-around stop when sieving reaches p > base, then restart from the file of remaining terms.

[QUOTE=rogue;549001]I found the cause. I'll try to get it fixed later today. The main issue is that it will slow down sieving for p > base. To work-around stop when sieving reaches p > base, then restart from the file of remaining terms.[/QUOTE]

Surely if it affects speed then mtsieve should detect when p becomes > base.

[QUOTE=henryzz;549016]Surely if it affects speed then mtsieve should detect when p becomes > base.[/QUOTE]

Correct, but the code to detect that condition (when starting a new base) had a bug.

[QUOTE=rogue;549019]Correct, but the code to detect that condition (when starting a new base) had a bug.[/QUOTE]

Sorry, I read it as you were only fixing it for newly resumed sieves but you had to restart manually in the fixed version.

k1b2sieve generalization
 

hey, i've just seen the k1b2sieve! is it possible to generalize this to an arbitrary base b, i.e. giving b as input instead of having b=2 fixed and sieving all b^n+c with n and c in a specified range? (i'd be interested in running such a sieve with base 10)

[QUOTE=matzetoni;549619]hey, i've just seen the k1b2sieve! is it possible to generalize this to an arbitrary base b, i.e. giving b as input instead of having b=2 fixed and sieving all b^n+c with n and c in a specified range? (i'd be interested in running such a sieve with base 10)[/QUOTE]

Yes, but it will be slower and not much faster than using fkbnsieve for each distinct n.

[QUOTE=rogue;549625]Yes, but it will be slower and not much faster than using fkbnsieve for each distinct n.[/QUOTE]


I see. Still, I'd like to run it over thousands of n, so it would eliminate the hassle of handling thousands of sieve files :)

[QUOTE=rogue;549625]Yes, but it will be slower and not much faster than using fkbnsieve for each distinct n.[/QUOTE]

Since 8+2=10

You can do it by 2 bitshift operations, 1 addition, 3-4 compare operations, 1 subtraction. Still faster than fkbnsieve for each individual n.

[QUOTE=Citrix;549663]Since 8+2=10

You can do it by 2 bitshift operations, 1 addition, 3-4 compare operations, 1 subtraction. Still faster than fkbnsieve for each individual n.[/QUOTE]

True, but I have avoided writing code that uses different logic for different bases.

If someone wants to hack the code to improve performance for a specific base or edge case, they are welcome to do so. The source code is freely available and can be built with tools that are free.

If someone has an algorithm that improves performance that is not specific to a base or edge case, then I would definitely consider updating the code base.

k1b2sieve.exe -P 100000000 -n1778899 -N2778899 -c1 -C2
k2b2sieve v1.0, a program to find factors of 2^n+c numbers for variable n and c


cosmetic bug
when you start k1b2sieve.exe first line say k2b2sieve v1.0


so or it is k1 or it is k2 :)


Also ( as nearly in any of your sieves in this package:) when you terminate sieve , and wait... got nothing for results. :(
To explain: I start sieve with parameters above, wait ten minutes, terminate it with CTRL+C and when program exit there is no sieve file

[QUOTE=pepi37;549823]k1b2sieve.exe -P 100000000 -n1778899 -N2778899 -c1 -C2
k2b2sieve v1.0, a program to find factors of 2^n+c numbers for variable n and c


cosmetic bug
when you start k1b2sieve.exe first line say k2b2sieve v1.0


so or it is k1 or it is k2 :)


Also ( as nearly in any of your sieves in this package:) when you terminate sieve , and wait... got nothing for results. :(
To explain: I start sieve with parameters above, wait ten minutes, terminate it with CTRL+C and when program exit there is no sieve file[/QUOTE]

Try version 1.1. I think that is the version in the current distribution on source forge.

proofer-account twinsieve/mtsieve ?
 

Hey,


I recently found a twinprime which is big enough to submit it to C. Caldwell's prime pages. I used twinsieve.exe for the sieving and LLR for the proof so I want to give all programmers credit for the find, I tried to create a new proof code for [me, LLR and twinsieve] but I am struggling to find twinsieve.exe or mtsieve as existing codes. Have I overlooked something or is there no code jet ?
Short question: What proofer-account should I use when I want to give credit to twinsieve/mtsieve ?


Thanks in advance.

[QUOTE=hunson;549835]Hey,


I recently found a twinprime which is big enough to submit it to C. Caldwell's prime pages. I used twinsieve.exe for the sieving and LLR for the proof so I want to give all programmers credit for the find, I tried to create a new proof code for [me, LLR and twinsieve] but I am struggling to find twinsieve.exe or mtsieve as existing codes. Have I overlooked something or is there no code jet ?
Short question: What proofer-account should I use when I want to give credit to twinsieve/mtsieve ?


Thanks in advance.[/QUOTE]

I think it is this one: [url]https://primes.utm.edu/bios/page.php?id=449[/url]

No prover code for mtsieve. I've asked about either creating a new one or switching MultiSieve over to mtsieve.

Sorry I have to ask again: Did you ask someone to change MultiSieve.exe to mtsieve respectively create a new prover code for mtsieve?
If there is a change, how do we know about it?


regards,


hunson

[QUOTE=hunson;549949]Sorry I have to ask again: Did you ask someone to change MultiSieve.exe to mtsieve respectively create a new prover code for mtsieve?
If there is a change, how do we know about it?[/QUOTE]

For now use MultiSieve, but I have a question to the owners of Prime Pages about it.

[QUOTE=hunson;549835]Hey,


I recently found a twinprime which is big enough to submit it to C. Caldwell's prime pages. I used twinsieve.exe for the sieving and LLR for the proof so I want to give all programmers credit for the find, I tried to create a new proof code for [me, LLR and twinsieve] but I am struggling to find twinsieve.exe or mtsieve as existing codes. Have I overlooked something or is there no code jet ?
Short question: What proofer-account should I use when I want to give credit to twinsieve/mtsieve ?


Thanks in advance.[/QUOTE]

The comment to your twin primes should be "Twin (p)" and "Twin (p+2)" -- you need to submit both. The UTM parser is very finickety.

Congrats!

I was afraid that I had to do that. Thanks for the clarification, but in my defence there is no obvious documentation :) Now I submitted the p+2 form too.

[QUOTE=hunson;549975]I was afraid that I had to do that. Thanks for the clarification, but in my defence there is no obvious documentation :) Now I submitted the p+2 form too.[/QUOTE]

It is not intuitive. WIBNI there was some kind of drop-down selector for the types?

Unless Chris Caldwell spots the error or someone notifies him of it, your entry will not be right and it will not register on the top20 of twins,

I posted 2.0.4 over at sourcforge. It fixes an issue in the factor rate calculation and adds sgsieve for Sophie-Germain searches.

[QUOTE=rogue;550198]I posted 2.0.4 over at sourcforge. It fixes an issue in the factor rate calculation and adds sgsieve for Sophie-Germain searches.[/QUOTE]

I didn't read up on the instruction, but as I see it, it is Sophie Germain for fixed exponent - is that correct? ... still it is not a problem, because I do well using sr2sieve - since I sieve a range of 100M n for each 32 k's. How is the timeframe of getting sr2sieve into srsieve2? :smile: ... also with the last request, no pressure, even though an 80% speedup would be very cool :smile:

[QUOTE=KEP;550259]I didn't read up on the instruction, but as I see it, it is Sophie Germain for fixed exponent - is that correct? ... still it is not a problem, because I do well using sr2sieve - since I sieve a range of 100M n for each 32 k's. How is the timeframe of getting sr2sieve into srsieve2? :smile: ... also with the last request, no pressure, even though an 80% speedup would be very cool :smile:[/QUOTE]

Sophie-Germain primes are numbers were p and 2p-1 are prime. For this sieve p = k*2^n+1 and it sieves for a fixed n and range of k since sieving that form does not require a discrete log.

Incorporating sr2sieve into srsieve2 requires a lot of work and a lot of testing. With other things going on in my life I have been less motivated. I still want to complete it, but I don't know when I will.

Mark , for x times I say: thanks for your work on mtsieve, but I ask myself did you ever even try to test new sieve before you release it?
Did you make simple test?


As many times before: new sieve : sgsieve- doesnot work


sgsieve -P 10000000000 -W6 -k4 -K100000000 -n 177000


This works perfectly and it is done very fast.
But when you wish to continue...


e:\MTSIEVE\MTSIEVE204>sgsieve -P 10000000000000 -W6 -i sg.abcd
sgsieve v1.0, a program to eliminate terms for Sophie-Germain prime searches for base 2, fixed n and variable k
Fatal Error: Line 1 is not a valid ABCD line in input file sg.abcd


Sg.abcd is file created with your program in step one...
Please fix this


And this ABCD file, cannot be converted to any other format ( like output from newpgen)

You force this ABCD. Give user option, freedom to choose, what option to use.
Thanks

[QUOTE=pepi37;550285]Mark , for x times I say: thanks for your work on mtsieve, but I ask myself did you ever even try to test new sieve before you release it?
Did you make simple test?


As many times before: new sieve : sgsieve- doesnot work


sgsieve -P 10000000000 -W6 -k4 -K100000000 -n 177000


This works perfectly and it is done very fast.
But when you wish to continue...


e:\MTSIEVE\MTSIEVE204>sgsieve -P 10000000000000 -W6 -i sg.abcd
sgsieve v1.0, a program to eliminate terms for Sophie-Germain prime searches for base 2, fixed n and variable k
Fatal Error: Line 1 is not a valid ABCD line in input file sg.abcd


Sg.abcd is file created with your program in step one...
Please fix this


And this ABCD file, cannot be converted to any other format ( like output from newpgen)

You force this ABCD. Give user option, freedom to choose, what option to use.
Thanks[/QUOTE]

Sorry, but I didn't test the continue sieving option. Should be easy to fix.

That I don't support newpgen just means that I haven't taken the time to do so. If llr can support the newpgen format for SG searches, then I will add support for it. Since I support pfgw I target sieve files supported by that program.

Note that I cannot anticipate everyone's needs or even who is going to use the software I write.

Since you have many output format you use in other sieves in this package why just dont copy to this sieve also. Lets say with current output from sgsieve I cannot do anything to process it in prime95. With npg output I can easy do it.
I dont think it is so hard to implement those output format

[QUOTE=pepi37;550294]Since you have many output format you use in other sieves in this package why just dont copy to this sieve also. Lets say with current output from sgsieve I cannot do anything to process it in prime95. With npg output I can easy do it.
I dont think it is so hard to implement those output format[/QUOTE]

In some cases I am trying to replicate functionality of another program that is no longer supported or if I know that I can write something faster. fermfact is a great example. In other cases I am not aware of anything equivalent to what I'm writing. And in other cases I'm taking an old program and making it giving it a speed boost. gcwsieve is a great example of that.

It is possible that you are making an assumption that all sieves share a piece of code for reading and writing their file of candidates. They do not because each program requires a different format. I lean towards ABCD for some because it is the most compact format and other formats create absolutely huge output files. Some of those programs cannot output in newpgen format as newpgen doesn't support those forms. In short I target pfgw and if llr works as well, that's great.

You might also be making the assumption that I use prime95. I have actually never run it. Both pfgw and llr use George's gwnum library. Those are the programs I predominantly use. Now if the output is not compatible with llr, then it is either "oh well" and I live with it or I change the sieving program or I ask Jean to add to llr. In the last case I would likely provide code to Jean and he would incorporate it. He has done that for me and for others.

Finally, the code is freely available to anyone to d/l and build. Many have done so, but few have assisted me in improving the software so I am pretty much a "one man band".

The alternative would be for someone to ask George or Jean to add full support of all ABCD and ABC file formats.

To put it simply, you have [b]no right to complain[/b]. You are getting software that is fast and free to use. As for bugs, I will fix them as soon as I am made aware. Complaining that my software doesn't meet a requirement that has never been stated is utterly ridiculous.

[QUOTE=pepi37;550294]Since you have many output format you use in other sieves in this package why just dont copy to this sieve also. Lets say with current output from sgsieve I cannot do anything to process it in prime95. With npg output I can easy do it.
I dont think it is so hard to implement those output format[/QUOTE]

Since mtsieve is open source, you can have whatever headers you like. Alter and compile.

If that is impossible a simple Perl script to do the conversion is easy to write.

[QUOTE=paulunderwood;550302]Since mtsieve is open source, you can have whatever headers you like. Alter and compile.

If that is impossible a simple Perl script to do the conversion is easy to write.[/QUOTE]


1. If it true ( that I can have whatever header I like) why Mark doesnot add in all sieves few headers / option for output?
Paul, maybe you compile with your closed eyes i to you it is simplest job in the universe, but does we all know how to alter headers ,and make it to compile later?
I think that is not case here ( on this forum)


2. Perl is language that is needed to be learn as any other thing in the world. So I will decode this ABCD in excel after I make initial sieve in newpgen and sgsieve so I have some to compare with.

[B]Mark, my deepest apologies if you find any of my word offensive. It was not and never will be intention[/B]

[QUOTE=pepi37;550304]1. If it true ( that I can have whatever header I like) why Mark doesnot add in all sieves few headers / option for output?
Paul, maybe you compile with your closed eyes i to you it is simplest job in the universe, but does we all know how to alter headers ,and make it to compile later?
I think that is not case here ( on this forum)


2. Perl is language that is needed to be learn as any other thing in the world. So I will decode this ABCD in excel after I make initial sieve in newpgen and sgsieve so I have some to compare with.

[B]Mark, my deepest apologies if you find any of my word offensive. It was not and never will be intention[/B][/QUOTE]

Apology accepted.

I am not perfect (and sometimes my code isn't either), but I aim to provide fast and easy to use software. The number of people and projects using my code is a testament to my efforts, especially if they have alternatives.

I will consider adding support for the newpgen format to sgsieve, but make no promises.

FYI, the ABCD format is described in a file include in the pfgw distribution. It can be a little cryptic to those who are not familiar with it, but it isn't as cryptic as the newpgen format. Whenever I see that format I have to look at the newpgen source code to make sense of it.

Last night I run Newpgen with same range for SG search and your new sgsieve.
Since I don't know does your sieve include odd k I make two test and found totally different number of candidates in output ( on same sieve depth)
So decoding ABCD was unsuccessful because I have no base point to decode.

[QUOTE=pepi37;550341]Last night I run Newpgen with same range for SG search and your new sgsieve.
Since I don't know does your sieve include odd k I make two test and found totally different number of candidates in output ( on same sieve depth)
So decoding ABCD was unsuccessful because I have no base point to decode.[/QUOTE]

Only odd k are included in sgsieve. I can run against newpgen and see what it produces.

I posted 2.0.5 to sourceforge. The only change is for sgsieve support of newpgen format. Note that the Sophie-Germain primes it searches for are referred to a "CC" by newpgen and twingen. In the future I will add support for p = k*b^n-1. Right now it only supports p = k*2^n+1. The future will also bring support for other bases.

Feature request for srsieve2.exe

In CisOneSubsequenceHelper.cpp can you create an option to bypass the code to calculate the ii_BestQ if the user can use the -Q flag and specify it from the command line.

Generally srsieve2.exe program can calculate the best Q but for some sequences (Q>720) it does not work and it might be better to specify it from the command line.

Thanks.

[QUOTE=Citrix;554160]Feature request for srsieve2.exe

In CisOneSubsequenceHelper.cpp can you create an option to bypass the code to calculate the ii_BestQ if the user can use the -Q flag and specify it from the command line.

Generally srsieve2.exe program can calculate the best Q but for some sequences (Q>720) it does not work and it might be better to specify it from the command line.[/QUOTE]

Seems reasonable enough. Do you know some sequences where Q > 720? It might be possible for srsieve2 to compute it, unless it would be extremely large.

[QUOTE=rogue;554188]Seems reasonable enough. Do you know some sequences where Q > 720? It might be possible for srsieve2 to compute it, unless it would be extremely large.[/QUOTE]

All candidates in post below need Q >720
[url]https://www.mersenneforum.org/showpost.php?p=355682&postcount=4[/url]

You can read the posts in the above thread (towards the end). We were finding benefit of using Q values greater than 50,000

You can also artificially create a sequence that needs Q>720 for testing

It would be best for a manual option for Q as some sequences require Q to be a multiple of 7,11 etc and it is hard for any algorithm to predict best Q in all possible circumstances.

Source 2.0.5.7
I cannot get that gfndsievecl. exe working
Ok it doesnot crash, but if use GPU then GPU load should not be zero?

[QUOTE=pepi37;555231]Source 2.0.5.7
I cannot get that gfndsievecl. exe working
Ok it doesnot crash, but if use GPU then GPU load should not be zero?[/QUOTE]

The first chunk that is tested will not use the GPU because of the large number of candidates removed. Beyond that it should use the GPU. Did you specify the -G option? Also note that this code doesn't stress the GPU that much. You could try upping the value for -G to start more GPU workers.

[QUOTE=rogue;555249]The first chunk that is tested will not use the GPU because of the large number of candidates removed. Beyond that it should use the GPU. Did you specify the -G option? Also note that this code doesn't stress the GPU that much. You could try upping the value for -G to start more GPU workers.[/QUOTE]


Yes it works , with -G2 -g 20 I got same speed as from one cpu worker!
Thanks for answer!


Cosmetic bug: if you use-i gfnd.pfgw -o gfnd.pfgw then output will be named gfnd.pfgw.pfgw, so you must use -o gfnd to get output gfnd.pfgw

[QUOTE=pepi37;555268]Yes it works , with -G2 -g 20 I got same speed as from one cpu worker!
Thanks for answer!

Cosmetic bug: if you use-i gfnd.pfgw -o gfnd.pfgw then output will be named gfnd.pfgw.pfgw, so you must use -o gfnd to get output gfnd.pfgw[/QUOTE]

You probably want to bump both -G and -g.

Auto-appending .pfgw to the output file name is intended in this case because of the -T option. I suppose I could change so that .pfgw is only appended if -T is specified thus making -O a prefix for file name instead of a file name.

[QUOTE=rogue;555271]You probably want to bump both -G and -g.

Auto-appending .pfgw to the output file name is intended in this case because of the -T option. I suppose I could change so that .pfgw is only appended if -T is specified thus making -O a prefix for file name instead of a file name.[/QUOTE]

I try that but got error: my card has only 6 GB of DDR6 , so it broke: it looks like 6 GB is not enough. On current settings it use 4 GB of RAM

By the way how to activate
-x --testterms test remaining terms for GFN divisibility

Can I just input number of candidate and try to test it without sieving or I need to done sieving and in next step application test remain candidates?


[QUOTE]e:\MTSIEVE\GFDN>gfndsievecl.exe -i gfnd.pfgw -x
gfndsieve v1.8, a program to find factors of k*2^n+1 numbers for variable k and n
Fatal Error: cannot use -i and -x together

e:\MTSIEVE\GFDN>pause[/QUOTE]


I try other combination but it doesnot work also :(

The reason is that -x is intended to be used on new sieves. It is also geared towards n < 2000. For larger n using gfndsieve+pfgw would be faster. Also other programs will likely be faster than gfndsieve for such small x.

[QUOTE=rogue;555282]The reason is that -x is intended to be used on new sieves. It is also geared towards n < 2000. For larger n using gfndsieve+pfgw would be faster. Also other programs will likely be faster than gfndsieve for such small x.[/QUOTE]

All you say is OK but if I wish to use your program what will be correct command?

[QUOTE=pepi37;555284]All you say is OK but if I wish to use your program what will be correct command?[/QUOTE]

What n range are you sieving?

[QUOTE=rogue;555300]What n range are you sieving?[/QUOTE]


-k 10000 -K 10050 -n 1600 -N 1610


just for test , but to know how to use x option

[QUOTE=pepi37;555302]-k 10000 -K 10050 -n 1600 -N 1610

just for test , but to know how to use x option[/QUOTE]

As long as you are not using -i, you can use -x. I assume that you are just testing the functionality. For that range of k and n feromant or pmts would be faster per [url]http://www.fermatsearch.org/productivity.html[/url]

[QUOTE=rogue;555328]As long as you are not using -i, you can use -x. I assume that you are just testing the functionality. For that range of k and n feromant or pmts would be faster per [URL]http://www.fermatsearch.org/productivity.html[/URL][/QUOTE]




e:\MTSIEVE\GFDN>gfndsievecl.exe -k 170000 -K 170050 -n 29900 -N 30000 -P 2000000000 -W6 -x
gfndsieve v1.8, a program to find factors of k*2^n+1 numbers for variable k and n
terminate called after throwing an instance of 'std::bad_alloc'
[I][COLOR=Magenta][B] what(): std::bad_alloc[/B][/COLOR]
[/I]

[QUOTE=pepi37;555396]e:\MTSIEVE\GFDN>gfndsievecl.exe -k 170000 -K 170050 -n 29900 -N 30000 -P 2000000000 -W6 -x
gfndsieve v1.8, a program to find factors of k*2^n+1 numbers for variable k and n
terminate called after throwing an instance of 'std::bad_alloc'
[I][COLOR=Magenta][B] what(): std::bad_alloc[/B][/COLOR]
[/I][/QUOTE]

It ran out of memory. Use -X to reduce the number of terms per chunk.

Since n is so large, you are much better off running without -x than using pfgw with the output file.

I have posted 2.0.6 at sourceforge. Here are the improvements:
[LIST][*]Fixed crash with xyyxsievecl with overly large ranges for the GPU.[*]More speed enhancements for xyyxsieve, mainly due to reduced memory requirements.[*]Do not show ETA or percent done if less than 1% done and -P not used.[*]Modify factor rate calculation to handle uneven factor distribution better.[*]Fix srsieve2 to not check for algebraic factors when abs(c) != 1.[*]Fix srsieve2 as it was counting factors of terms that had already been removed.[/LIST]
srsieve2 has some issues for (k*b^n+c)/d that are not fully worked out. The main ones are the removal of terms if d does not divide k*b^n+c and factors of (k*b^n+c)/d if gcd(d, p) > 1 and gcd(d, p) != p. I would appreciate if anyone could write some code to assist in those areas.

What is the best way to convert fkbnsieve output to abc format rather than abcd?

For anyone that uses Arch Linux or its derivatives, I've [URL="https://aur.archlinux.org/packages/mtsieve/"]made mtsieve into an AUR package[/URL]. All that's needed to install it is to run

[code]pikaur -S mtsieve[/code]and you can install the full suite.

The latest srsieve2 has still worker issues where not all workers are used. This is happening around 2 of 10 bases and only 1 core is active.

[CODE]srsieve2 -n2501 -N10000 -P1e9 -W16 -spl_remain.txt -fB[/CODE]In this case Iam using the srsieve2 file from 16.01.2020 without a problem.

[QUOTE=rebirther;562612]The latest srsieve2 has still worker issues where not all workers are used. This is happening around 2 of 10 bases and only 1 core is active.

[CODE]srsieve2 -n2501 -N10000 -P1e9 -W16 -spl_remain.txt -fB[/CODE]In this case Iam using the srsieve2 file from 16.01.2020 without a problem.[/QUOTE]

Do you mean the the one from earlier this year works correctly and the newer one does not?

[QUOTE=rogue;562633]Do you mean the the one from earlier this year works correctly and the newer one does not?[/QUOTE]


correct

GPU support for gcwsieve is broken on Intel GPUs:

[CODE]C:\Users\Yao.Yao2016\ck2\mtsieve>gcwsievecl -W 4 -G 100 -s + -b 12 -n 254520 -N
600000 -o 12CullenSearch.txt
gcwsieve v1.3, a program to find factors numbers of the form n*b^n+1 and n*b^n-1

8 terms removed due to algebraic factorizations
OpenCL Error: Program build failure
in call to clBuildProgram
2:6:26: error: OpenCL extension 'cl_khr_int64_base_atomics' is unsupported
2:55:15: warning: use of logical '&&' with constant operand
2:55:15: note: use '&' for a bitwise operation
2:55:15: note: remove constant to silence this warning[/CODE]Please fix it.


Edit: I did some Google searches and found out it was a problem with my computer regarding something being unsupported. How do I fix it? I'm using an Intel GPU on Windows 7 4 cores.

[QUOTE=YaoPlaysMC;563609]Edit: I did some Google searches and found out it was a problem with my computer regarding something being unsupported. How do I fix it? I'm using an Intel GPU on Windows 7 4 cores.[/QUOTE]

Buy a discrete GPU? If your GPU doesn't support some OpenCL instructions, seems your options are different hardware or run different software.

[QUOTE=YaoPlaysMC;563609]GPU support for gcwsieve is broken on Intel GPUs:

[CODE]C:\Users\Yao.Yao2016\ck2\mtsieve>gcwsievecl -W 4 -G 100 -s + -b 12 -n 254520 -N
600000 -o 12CullenSearch.txt
gcwsieve v1.3, a program to find factors numbers of the form n*b^n+1 and n*b^n-1

8 terms removed due to algebraic factorizations
OpenCL Error: Program build failure
in call to clBuildProgram
2:6:26: error: OpenCL extension 'cl_khr_int64_base_atomics' is unsupported
2:55:15: warning: use of logical '&&' with constant operand
2:55:15: note: use '&' for a bitwise operation
2:55:15: note: remove constant to silence this warning[/CODE]Please fix it.


Edit: I did some Google searches and found out it was a problem with my computer regarding something being unsupported. How do I fix it? I'm using an Intel GPU on Windows 7 4 cores.[/QUOTE]

The best way to handle would be for the code to detect that the GPU you are trying to use doesn't support the extension and give a better message upon execution. At this time I do not know how to do that.

Are you looking for something like [URL="http://subscription.packtpub.com/book/application_development/9781849694520/1/ch01lvl1sec11/querying-for-opencl-device-extensions"]this[/URL]?

[QUOTE=kruoli;563650]Are you looking for something like [URL="http://subscription.packtpub.com/book/application_development/9781849694520/1/ch01lvl1sec11/querying-for-opencl-device-extensions"]this[/URL]?[/QUOTE]

Thanks. I'll keep that in mind for a future release.

[QUOTE=YaoPlaysMC;563609]GPU support for gcwsieve is broken on Intel GPUs[/quote]

You can still run gcwsieve (as opposed to gcwsievecl). With the AVX boost, it is pretty fast.

fkbnsieve v1.2 (mtsieve 1.9.6)

Just tried for fun different ranges, but I cannot get it to work. For example:
fkbnsieve.exe -c 1 -C 4000000000 -P 4000000000 -s "1*2^65+c"

It just stops after a few sieve primes without any error message and without writing the remaining candidates.

I tried with a higher exponent or some k>1 or base 3 or different -c and -C but everytime it stops after a different low primes like p=7, p=659, p=3119, p=3221 depending on which parameters I used. For the same parameters it stops at the same prime each time.



Another issue probably cosmetic: If you use a large interval of c-values like >8e9 it writes p=0 in the progress report for a while. Not sure if that is intended, probably because p=3 takes a long time to complete?
p=0, 0.000 p/sec, 14294950138 factors found at 58.43M f/sec, 0.0% done.

[QUOTE=ATH;564671]fkbnsieve v1.2 (mtsieve 1.9.6)

Just tried for fun different ranges, but I cannot get it to work. For example:
fkbnsieve.exe -c 1 -C 4000000000 -P 4000000000 -s "1*2^65+c"

It just stops after a few sieve primes without any error message and without writing the remaining candidates.

I tried with a higher exponent or some k>1 or base 3 or different -c and -C but everytime it stops after a different low primes like p=7, p=659, p=3119, p=3221 depending on which parameters I used. For the same parameters it stops at the same prime each time.



Another issue probably cosmetic: If you use a large interval of c-values like >8e9 it writes p=0 in the progress report for a while. Not sure if that is intended, probably because p=3 takes a long time to complete?
p=0, 0.000 p/sec, 14294950138 factors found at 58.43M f/sec, 0.0% done.[/QUOTE]


I try on newer version and with short range , works ok


[QUOTE]C:\Users\I5-ALPHA>E:\MTSIEVE\MTSIEVE205\fkbnsieve.exe -c 1 -C 400000 -P 4000000 -s "1*2^65+c"
fkbnsieve v1.3, a program to find factors of k*b^n+c numbers for fixed k, b, and n and variable c
Sieve started: 1 < p < 4e6 with 400000 terms (1 <= c <= 400000, 1*2^65+c) (expecting 381761 factors)
Sieve completed at p=4000043.
Processor time: 7.23 sec. (0.00 sieving) (0.98 cores)
14935 terms written to k1_b2_n65.pfgw
Primes tested: 283152. Factors found: 385065. Remaining terms: 14935. Time: 7.38 seconds.[/QUOTE]


Try new(er ) version. I dont see this kind of sieve in latest release

[QUOTE=ATH;564671]fkbnsieve v1.2 (mtsieve 1.9.6)

Just tried for fun different ranges, but I cannot get it to work. For example:
fkbnsieve.exe -c 1 -C 4000000000 -P 4000000000 -s "1*2^65+c"

It just stops after a few sieve primes without any error message and without writing the remaining candidates.

I tried with a higher exponent or some k>1 or base 3 or different -c and -C but everytime it stops after a different low primes like p=7, p=659, p=3119, p=3221 depending on which parameters I used. For the same parameters it stops at the same prime each time.

Another issue probably cosmetic: If you use a large interval of c-values like >8e9 it writes p=0 in the progress report for a while. Not sure if that is intended, probably because p=3 takes a long time to complete?
p=0, 0.000 p/sec, 14294950138 factors found at 58.43M f/sec, 0.0% done.[/QUOTE]

Yes, for small p and large ranges, this is expected. The main reason is that all factors are verified. That cannot be disabled.

If you still have a problem with the latest version, please let me know.

[QUOTE=pepi37;564695]Try new(er ) version. I dont see this kind of sieve in latest release[/QUOTE]

Ok, thanks.

I did check for a new version before posting, but I checked in post #1 in this thread which links to:
[url]https://mersenneforum.org/rogue/mtsieve.html[/url]

and that page still has link to mtsieve 1.9.6, maybe add the sourceforge link to that page?

[QUOTE=ATH;564700]Ok, thanks.

I did check for a new version before posting, but I checked in post #1 in this thread which links to:
[URL]https://mersenneforum.org/rogue/mtsieve.html[/URL]

and that page still has link to mtsieve 1.9.6, maybe add the sourceforge link to that page?[/QUOTE]




[URL]https://sourceforge.net/projects/mtsieve/files/mtsieve_2.0.6.7z/download[/URL]

I updated the html months ago, but apparently never posted it. The mtsieve home page has been updated.

fkbnsieve v1.3 (mtsieve 2.0.6) works, but seems very slow compared to when I used it before. The p=3 step is running very slowly even with c-ranges of a few million only removing a few thousands factors per second.

[CODE]fkbnsieve.exe -c 1 -C 1000000 -P 400000000 -s "1*2^65+c"
Primes tested: 21336332. Factors found: 972437. Remaining terms: 27563. Time: 48.53 seconds.

fkbnsieve.exe -c 1 -C 2000000 -P 400000000 -s "1*2^65+c"
Primes tested: 21336332. Factors found: 1944946. Remaining terms: 55054. Time: 190.56 seconds.

fkbnsieve.exe -c 1 -C 4000000 -P 400000000 -s "1*2^65+c"
Primes tested: 21336332. Factors found: 3889879. Remaining terms: 110121. Time: 758.98 seconds.

fkbnsieve v1.1:
fkbnsieve.exe -c 1 -C 4000000 -P 400000000 -s "1*2^65+c"
Primes tested: 21336328. Factors found: 972437. Remaining terms: 27563. Time: 1.73 seconds.[/CODE]


This last one taking 758.98s takes only 1.73s in fkbnsieve v1.1 (mtsieve 1.8.4)

I'll just use fkbnsieve v1.1 for now, but I wanted to report it in case it is a bug.

[QUOTE=ATH;564721]fkbnsieve v1.3 (mtsieve 2.0.6) works, but seems very slow compared to when I used it before. The p=3 step is running very slowly even with c-ranges of a few million only removing a few thousands factors per second.

[CODE]fkbnsieve.exe -c 1 -C 1000000 -P 400000000 -s "1*2^65+c"
Primes tested: 21336332. Factors found: 972437. Remaining terms: 27563. Time: 48.53 seconds.

fkbnsieve.exe -c 1 -C 2000000 -P 400000000 -s "1*2^65+c"
Primes tested: 21336332. Factors found: 1944946. Remaining terms: 55054. Time: 190.56 seconds.

fkbnsieve.exe -c 1 -C 4000000 -P 400000000 -s "1*2^65+c"
Primes tested: 21336332. Factors found: 3889879. Remaining terms: 110121. Time: 758.98 seconds.

fkbnsieve v1.1:
fkbnsieve.exe -c 1 -C 4000000 -P 400000000 -s "1*2^65+c"
Primes tested: 21336328. Factors found: 972437. Remaining terms: 27563. Time: 1.73 seconds.[/CODE]


This last one taking 758.98s takes only 1.73s in fkbnsieve v1.1 (mtsieve 1.8.4)

I'll just use fkbnsieve v1.1 for now, but I wanted to report it in case it is a bug.[/QUOTE]

I will have to look into what changed. If I had to suspect anything I would suspect the the older version did not have working factor validation.

I cannot find fkbnsieve.exe in latest release ( in 7z file)
Also can srsieve2 sieve in parallel few sequences or just one by one?

If by "in parallel" you mean multi-threaded, yep.

[QUOTE=VBCurtis;564774]If by "in parallel" you mean multi-threaded, yep.[/QUOTE]


No :)
I mean to sieve few sequence in same time ( like I can with sr2sieve)

[QUOTE=pepi37;564775]No :)
I mean to sieve few sequence in same time ( like I can with sr2sieve)[/QUOTE]

Yes. You can use -s multiple times on the command line.

[QUOTE=rogue;564742]I will have to look into what changed. If I had to suspect anything I would suspect the the older version did not have working factor validation.[/QUOTE]

The slowdown is due to a change to the factor verification code. Previously it would compute k*b^n once regardless of how many c that are divisible by p. I changed to recompute k*b^n for each factor. The reason is that I wanted to guarantee the use of a different algorithm for the verification of a factor. I might be able to make changes to help on the speed, but I'll have to look into it.

In short, this will only impact you for small p. Once p > maxC - minC, the speed will be the same.

[QUOTE=rogue;564778]Yes. You can use -s multiple times on the command line.[/QUOTE]


Great news! Save alot of time!
Thanks!

Rogue one suggestion for all sieve programs in mtsieve package.


When using with -I -A ( apply factors and exit) add simple logic to check is factors really factors.
I accidentally make wrong copy paste and srsieve2 remove candidate regardless fact ( because error) that was not good factor for that candidate.

That shouldn't be hard to do.

Also, don't report a fatal error when running the programs with the "--help" switch. It's unnecessarily scary.

[QUOTE=Happy5214;565028]Also, don't report a fatal error when running the programs with the "--help" switch. It's unnecessarily scary.[/QUOTE]

I've gone back and forth on that. Technically the programs allow you to sieve even if you used -h, but I could probably make an exception in this case.

[QUOTE=rogue;565048]I've gone back and forth on that. Technically the programs allow you to sieve even if you used -h, but I could probably make an exception in this case.[/QUOTE]

Most programs only display help with -h

[QUOTE=henryzz;565050]Most programs only display help with -h[/QUOTE]

Changing the behavior for -h is easy, but after looking at the code I can say that factor validation of files input with -I is going to take more time.

Can you make a program for sieving Generalized Unique primes of the form Phi(3, -k^b)?

[QUOTE=YaoPlaysMC;565948]Can you make a program for sieving Generalized Unique primes of the form Phi(3, -k^b)?[/QUOTE]

I suggest that you start with the Prime Pages and search for "Generalized Unique" to see if any of those primes were found with the help of sieving software that you can use.

I'm not saying that I don't want to do this. I just don't want to cover ground done by someone else, unless I believe that I can write something either more accessible to the average use or much faster than what's available.

Can you make a program to sieve generalized Gaussian Mersenne primes of the form ((b^n-1)^2+1)/2?



Side note: These numbers are considered to be half-GFN because they are of the form (k^2+1)/2

[QUOTE=YaoPlaysMC;568517]Can you make a program to sieve generalized Gaussian Mersenne primes of the form ((b^n-1)^2+1)/2?

Side note: These numbers are considered to be half-GFN because they are of the form (k^2+1)/2[/QUOTE]

Possibly. Is there an efficient way to sieve them?

I have posted 2.1.3 over at sourceforge. Here are the changes:

[code]
framework:
Improve determination of "largest prime" tested for per minute stats by ignoring
workers that haven't done any work.

dmdsieve: version 1.3
Added working factor validation logic with -I.
Modify factor validation logic to only verify the first 5 factors for each small
prime. If there is a problem it will reveal itself immediately. This improves
the speed when starting a new sieve.

gnfdsieve, gfndsievecl: version 1.9
Added working factor validation logic with -I.
Modify factor validation logic to only verify the first 5 factors for each small
prime. If there is a problem it will reveal itself immediately. This improves
the speed when starting a new sieve.
Allow the GPU to start sieving at (kMax-kMin)/2 instead of kMax.
Switched to Montgomery mulitplication in the GPU.
Changed GPU code to handle "too many factors" similar to other GPU sievers in the
framework as opposed to crashing if not enough GPU memory.
GPU code is about 9x faster than CPU code, but GPU code is only of value if one
needs to sieve more deeply than (kMax-kMin)/2, which is somwhere over n=1000.

mfsieve: version 1.9
Used vectorized Montgomery logic to get a 1% to 5% speed boost.

srsieve2: version 1.3.1
Modify factor validation logic to only verify the first 5 factors for each small
prime. If there is a problem it will reveal itself immediately. This improves
the speed when starting a new sieve.
[/code]

[CODE] p=24662984657, 428.2K p/sec, 2771 factors found at 13.13 sec per factor, 98.6% done. ETC 2021-01-10 03:06
Sieve completed at p=25000000013.
Processor time: 9358.14 sec. (15.48 sieving) (3.87 cores)[/CODE]


I wonder how he took 15,48 for sieving. Maybe its just an error, i used srsieve v 1.1 with the -W 4 flag.

This is the first time sieving goes above 1 for me :D

[QUOTE=MisterBitcoin;568881][CODE] p=24662984657, 428.2K p/sec, 2771 factors found at 13.13 sec per factor, 98.6% done. ETC 2021-01-10 03:06
Sieve completed at p=25000000013.
Processor time: 9358.14 sec. (15.48 sieving) (3.87 cores)[/CODE]

I wonder how he took 15,48 for sieving. Maybe its just an error, i used srsieve v 1.1 with the -W 4 flag.

This is the first time sieving goes above 1 for me :D[/QUOTE]

The framework differentiates the time used to generate a list of primes for testing vs the rest of the execution time. You can see that a tiny percentage of time is needed for sieving compare to the function that looks for factors given a list of primes.