srsieve windows binaries
 

I have compiled some [url=http://www.geocities.com/g_w_reynolds/srsieve/]Windows binaries[/url], the i586 version should run on anything newer then a 486, the i686 version has the CMOV optimisations.

I have compiled these from Linux using a mingw32 cross-compiler, I briefly tested them on windows xp and there seems to be a problem with the clock function, but works otherwise. It may take me a little while to fix this as there is a lag of a day between compiling and testing. (my testing machine is the local library computer :-)

Please report any other bugs, including usability problems. When we can go a week without a bug report I will call this version 1.0.

edit: It seems there are more serious problems with the screen output, don't use these for serious work but if anyone can figure out what is going wrong I would appreciate it. The main program seems to be working, but the screen output is nonsense :-(

The message above refers to version 0.1.9. The problem was printf not printing 64 bit values correctly, I have fixed it in version 0.1.10.

If the moderators want to delete this message and the one above that would be fine with me :-) If not then please ignore the mess above and read the next post.

Working srsieve windows binaries
 

I have compiled [url=http://www.geocities.com/g_w_reynolds/srsieve/]srsieve Windows binaries[/url], the i586 version should work on any machine newer than a 486, the i686 version has the CMOV optimisations.

I have tested them for a whole ten minutes on Windows xp, so please report any bugs or anything that just doesn't look right. If a week goes by without a bug report then I will call it version 1.0 and you will be stuck with it :-)

srsieve has been reasonably well tested for base 5 data on Linux, I am using it full time and checking the results, it hasn't produced any false negatives or positives. I don't have an easy way to test it on other platforms, so any help will be much appreciated.

Is it any quicker then NewPGen, and if so, how much?

[QUOTE=michaf]Is it any quicker then NewPGen, and if so, how much?[/QUOTE]
For sieving one candidate at a time it is a little quicker then NewPGen, about 25%-50% depending on size of p and hardware.

For sieving with multiple candidates (which NewPGen can't do) it is much faster. Sieving four times more candidates in srsieve only increases the time taken by a factor of two.

I've been using JJsieve for sierpinski base 4 candidates...how does srsieve compare? sorry haven't had resources to check for myself...

Thanks~

[QUOTE=tcadigan]I've been using JJsieve for sierpinski base 4 candidates...how does srsieve compare? sorry haven't had resources to check for myself...[/QUOTE]
I think jjsieve is for base 2^n only, but I may be wrong, I can't find the source anywhere to check.

My comparison of srsieve vs NewPGen speed was for base 5, NewPGen may well be faster for base 2^n.

I've posted P4 and Athlon binaries for version 0.1.15, let me know if there are other variations I should make.

Version 0.1.15 contains some base-5 specific code, the 64 bit sieve seems to be more than 30% faster on my P4 when sieving base 5 numbers, but only about 10% faster on my P3.

If anyone is able to compare version 0.1.14 with 0.1.15 on an AMD machine for base 5 sieving I would be interested to know how much faster it is. (I suspect it will be closer to 10% than 30% though).

On my P4, the sieve went from about 5500 p/sec to about 7100 p/sec
(on 5.2M candidates)

very impressive!! thank :)

[QUOTE=michaf]On my P4, the sieve went from about 5500 p/sec to about 7100 p/sec
(on 5.2M candidates)[/QUOTE]
I think the reason the P4 gets the best improvement is that it is not well suited to the current FPU based assembler routines. The base-specific code doesn't use the FPU.

Ah... so I get a lot of improvement because my processor s*cks :>

To move efficiently, I'd be doing only prp-ing on that processor, and let the sieving being handled by someone else?