sr2sieve client

[benjackson]

Originally Posted by geoff

For this project, older pentium 4's (Prescott and earlier) should gain up to 15% from version 1.7.6 compared to version 1.6.18, but results are a bit mixed on other machines. Any comparisons with version 1.6.18, especially on 32-bit machines, would be welcome.

(Beware that 1.7.x versions currently use elapsed time instead of CPU time, so for a direct comparison run version 1.6.18 it is necessary to use the -e switch or else to make sure that nothing else is running on the same CPU).

On a C2D under 64bit Linux I'm seeing 1550 kp/sec per core instead of ~1480 before, both versions just running ./sr2sieve -sv

[geoff]

Originally Posted by VJS

On a dual or quad core CPU is there any reason to believe that specifiying affinities to particular CPU core for each instance is superior to simply running them with no affinities?
Or identifying half the cache for core2duo's for each instance etc...

When combining sr2sieve and LLR on a multi-core CPU with hyperthreading, it is probably more efficient to run one LLR process on one real core (leaving one virtual core idle) and two sr2sieve processes on another real core (one per virtual core), rather than leaving it up to the operating system. I haven't tested this though.

On a fast machine sr2sieve usually does thousands of iterations per timeslice, so setting affinity to a particular core isn't necessary if each core is identical. (It shouldn't hurt performance much if sr2sieve gets each timeslice on a different core).

[umccullough]

I just finished porting the latest sr2sieve (1.7.9) to Haiku (http://haiku-os.org) this morning - and now I need to test it out...

What's the preferred method for testing a sieve client? Is there a good well-known range to test with?

I suppose I could just choose a random range, test it on linux, and then test it on Haiku. Considering I have both OSes on the same P4 2.8ghz, I can do a good performance comparison as well (since Haiku is pre-alpha, unoptimized, and uses gcc2.95.3 - i'm guessing there is likely to be a noticeable difference :P )

Anyhow, any suggestions?

[mdettweiler]

Originally Posted by umccullough

I just finished porting the latest sr2sieve (1.7.9) to Haiku (http://haiku-os.org) this morning - and now I need to test it out...

What's the preferred method for testing a sieve client? Is there a good well-known range to test with?

I suppose I could just choose a random range, test it on linux, and then test it on Haiku. Considering I have both OSes on the same P4 2.8ghz, I can do a good performance comparison as well (since Haiku is pre-alpha, unoptimized, and uses gcc2.95.3 - i'm guessing there is likely to be a noticeable difference :P )

Anyhow, any suggestions?

Well, I'm sure just about any range will work--you might want to try downloading the sr5check package from Geoff's site, he used it for public testing/benchmarking of various sr2/5sieve clients (it's based on the SR5 sieve file, I think, though that will work fine with sr2sieve, since sr2sieve is just like sr5sieve except generalized for all bases). It's got a pre-set range and sieve file you can use, and then a file containing all the factors that the range should contain--you simply need to then check the factors file you get and the known good factors file, and you're all set.

[umccullough]

Thanks!

In the meantime I just reserved a 10G range and have it running under Linux currently.

Once that is done, I'll run it on the Haiku client I built and see how it compares.

I'll definitely take a look at the sr5check though when I get a chance!

[umccullough]

Woohoo! This client is slow as molasses :P (the linux client on the same machine is 5-6x faster)

Probably because I compiled it with USE_ASM=no - I didn't really investigate why the ASM fails to compile, but I suspect it's simply because I am compiling with gcc2.95.3.

Soon Haiku should have a native gcc4 toolchain as well, and then I can give it another go to see how that works.

Otherwise the client appears to be working OK :)

[VJS]

look for a new dat should provide a little speed bump let us know how much, i havn't had a good chance to test the speed increase.

[dspdude2000]

I'm using the BOINC client to run sr2sieve on three different computers. It appears to me that there is no decrease in the time it takes to sieve 0.5 GB. In fact, I've measured a very slight increase. Based on a post I found elsewhere, I think the speed increase should be approximately 1-sqrt(16/17)=3% but I'm not seeing it. There is some variability in the sieving times so maybe I've just had bad luck lately (or something). I'm not too worried about it but I'd be interested in what other people are seeing.

[thommy]

Then you run primegrid? See this post: http://www.primegrid.com/forum_threa...wrap=true#8675
The work unit range has been increased from 0.5 to no idea to get appriximately same runtimes. So its not that easy to compare.

[dspdude2000]

Oh, you're right. That seems needlessly confusing. I guess I'd have to run sr2sieve manually to make a comparison. Maybe I'll do that.

[dspdude2000]

Sieving 1G with the old and new dat files on a 1.5GHz P-4 resulted in a 3.5% speedup. If the k=265711 sequence was typical, I think this means we will actually see a 2.6% slowdown in finding factors.