Experimenting with ksieve
 

I have sieved a range of "n" using ksieve2s. The only file being created is [I]*.del[/I] and readme tells me to use [I]abccreat.pl[/I] script to create an [I]*.abc[/I] file then...
Now - I have installed ActivePERL, however when running the [i]abccreat.pl[/i] script I get the following message twice:
[quote]Use of uninitialized value in concatenation (.) or string at C:\ksieve\abccreat.pl line 59.[/quote]
The *.abc file is created anyways but what does this message mean?
For the reference line 59 contains the following:
[quote]print "ABC $goth", '$a', "$gotm\n";[/quote]
Am I missing something?
P.S.
The output [i]*.abc[/i] file contains [B]all[/B] the n values in given range, so there is definitely something wrong...

OK... I had to convert [i]abcreate.pl[/i] to [i]*.bat[/i] file using [i]pl2bat utility[/i] and it works now :-)
Now, how to make result file usable with LLR - the file looks like this:
[quote]ABC 151515*2^$a-1
400003
400008
400022
400025
400028[/quote]

From the command line enter something like this (Linux-like, using cygwin):
$ ./abccreat.pl -n=200000-400000 < to32.del_9 > 460735275.txt
Header: k=460735275

The "Header" line is output by abccreat. Where [I]to32.del_9[/I] is the .del file containing something like
[QUOTE]
29 | 460735275*2^200001-1 +28...
37 | 460735275*2^200010-1 +36...
47 | 460735275*2^200016-1 +23...
53 | 460735275*2^200013-1 +52...
59 | 460735275*2^200008-1 +58...
[/QUOTE]
To adjust the file for LLR change the first line to something like
2450000000032:M:0:2:258
the first number is the sieving limit and is ignored by LLR, and add k to each line (using an editor like emacs or TextPad). This can be done from the command line too, using awk, will post this in a moment.

You need [I]awk[/I], if you have it type
awk -f abc2txt.txt 151515.abc > 151515.txt

The [I]abc2txt.txt[/I] file is attached, only 3 lines. You can change the sieve limit if you plan to use NewPGen later.[I] Edit[/I]: The hint to use [I]awk[/I] and the file were provided by LSoule.

BTW, for [I]k[/I] as small as 151515 NegPGen is faster :question: ksieve is faster than NewPGen for large k's that NewPGen can handle only as product of its factors, IMO.

Thanks for your hints!
Anyways, I have tested both ksieve2s and newpgen under the following conditions:
k=151515
n=400000-600000
pmax=1000000000

Results:
ksieve2s: 12 min. 30 sec., 25270 candidates left
newpgen: 7 min. 11 sec., 25270 candidates left

The test was performed on Athlon 64 X2 @ 2.45GHz. So it looks like I stick with newpgen for a moment :smile:
BTW: Is there any sieve program that would benefit from x86-64 instruction set? I am planning to migrate to WinXP x64 soon :smile:

[QUOTE=Cruelty]Is there any sieve program that would benefit from x86-64 instruction set? [/QUOTE] I think no prime-search related applications have any optimizations beyond SSE-2 in GIMPS and LLR (and reportedly in NewPGen but I see no dramatic speed-up with respect to Athlon for example). The development of a new sieve program that will unify ProhtSieve and RieselSieve is under way but it appears it's not best suited for k's divisible by 3 and I have no idea are they going to have any cpu-specific optimizations. BTW, what cpu exactly to you have in mind?

[QUOTE=Kosmaj]BTW, what cpu exactly to you have in mind?[/QUOTE]
Entire Athlon 64 family of CPUs.
[QUOTE=Kosmaj]I think no prime-search related applications have any optimizations beyond SSE-2 in GIMPS and LLR [/quote]
I think GIMPS is benefiting a lot from x86-64, at least as far as trial factoring is concerned...

I have just started sieve with ksieve2m for 4 k's in range 600000<n<800000.
I am worried however, as I am receiving a lot of following error messages:

"ErkMH, ran out of hash slots for prime xxxxxxx".

There is no documentation on what this error mean so I am stuck :surrender
Any hints?

I am using a following command to launch ksieve2m:
[code]ksieve2m -m -k=617 -k=12345 -k=151515 -k736320585 -p=2-6000000000000[/code]

Word on the street is that those messages are ok and can be ignored.
Some of my runs get a few of these and some get a LOT.

I simply LOVE error messages that I can ignore :rolleyes: I just hope that I won't miss any prime by doing so...

Can I resume sieving on the existing "*.del_?" files, or should I split it and then merge it using "abcmerge.pl" script?

BTW: what is the [B]proper[/B] way to use "delcheck.pl" script? I am just getting the following output (just as an example) which obviously doesn't make any sense:

[code]
if(lift(617*Mod(2,194003189353)^739059-1)!=0,print("194003189353 739059 bad"))
if(lift(617*Mod(2,194010479711)^717047-1)!=0,print("194010479711 717047 bad"))
if(lift(617*Mod(2,194022821791)^789331-1)!=0,print("194022821791 789331 bad"))
if(lift(617*Mod(2,194052806281)^646135-1)!=0,print("194052806281 646135 bad"))
if(lift(617*Mod(2,194068623967)^724651-1)!=0,print("194068623967 724651 bad"))
if(lift(617*Mod(2,194080049003)^612639-1)!=0,print("194080049003 612639 bad"))
if(lift(617*Mod(2,194132304557)^692805-1)!=0,print("194132304557 692805 bad"))
if(lift(617*Mod(2,194133494761)^619421-1)!=0,print("194133494761 619421 bad"))
if(lift(617*Mod(2,194171460941)^707996-1)!=0,print("194171460941 707996 bad"))
[/code]