Experimenting with ksieve

[Cruelty]

I have sieved a range of "n" using ksieve2s. The only file being created is *.del and readme tells me to use abccreat.pl script to create an *.abc file then...
Now - I have installed ActivePERL, however when running the abccreat.pl script I get the following message twice:

Use of uninitialized value in concatenation (.) or string at C:\ksieve\abccreat.pl line 59.

The *.abc file is created anyways but what does this message mean?
For the reference line 59 contains the following:

print "ABC $goth", '$a', "$gotm\n";

Am I missing something?
P.S.
The output *.abc file contains all the n values in given range, so there is definitely something wrong...

[Cruelty]

OK... I had to convert abcreate.pl to *.bat file using pl2bat utility and it works now :-)
Now, how to make result file usable with LLR - the file looks like this:

ABC 151515*2^$a-1
400003
400008
400022
400025
400028

[Kosmaj]

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 to32.del_9 is the .del file containing something like

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...

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.

[Kosmaj]

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

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

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

[Cruelty]

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
BTW: Is there any sieve program that would benefit from x86-64 instruction set? I am planning to migrate to WinXP x64 soon

[Kosmaj]

Originally Posted by Cruelty

Is there any sieve program that would benefit from x86-64 instruction set?

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?

[Cruelty]

Originally Posted by Kosmaj

BTW, what cpu exactly to you have in mind?

Entire Athlon 64 family of CPUs.

Originally Posted by Kosmaj

I think no prime-search related applications have any optimizations beyond SSE-2 in GIMPS and LLR

I think GIMPS is benefiting a lot from x86-64, at least as far as trial factoring is concerned...

[Cruelty]

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
Any hints?

I am using a following command to launch ksieve2m:

ksieve2m -m -k=617 -k=12345 -k=151515 -k736320585 -p=2-6000000000000

[lsoule]

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.

[Cruelty]

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

[Cruelty]

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 proper way to use "delcheck.pl" script? I am just getting the following output (just as an example) which obviously doesn't make any sense:

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"))