celeron 1700 MHz
v.41 shows 170 k/s max.
v.40 shows 200 k/s max.
doing 666000 range. same with 500000 range.
but as I say this 170 k/s is stable, and v.40 moves from 200 k/s to 100 or even 60 k/s and back...
That's odd. Could you post what cpus you're using along with those numbers? I can imagine that 0.41 might be slower on non-athlons. Also, what ranges are you doing?
PIII-1000
v.040cmov 279 kp/sec
v.041cmov 255 kp/sec
v.041sse2 crashes (040sse does not)
PIII-something
v.040cmov 236 kp/sec
v.041cmov 221 kp/sec
PIV-something
v.040sse2 143 kp/sec
v.041sse2 180 kp/sec ===> 26% speed increase!!!! I'm not complaining or anything, but is there something wrong with this???
PS: I'll try it with another PIV later and post it's result.
Alright, don't put too much effort into testing 0.41. I'll have a new one out soon.
As for the SSE2 crashing on P3 -- it should do that. Strange that 0.40SSE2 didn't.
26% up P4 sounds a bit much, but not wholly unreasonable.
Ok, give 0.42 a try. http://n137.ryd.student.liu.se/proth_sieve.php
This one should give better speed for SOBbers. I see a slight speed increase from 0.40. Let me know what you see.
Mikael
my speeds (see post above) were on an AMD Athlon XP (Barton) 2800+ overclocked slightly to 2224.42mhz (approx. 3000+)
Last edited by Deoje; 02-12-2004 at 03:01 PM.
celeron 400@411, based on pII, 128kb L2cache
proth_sieve_cmov 0.40 107-108 kp/s
proth_sieve_cmov 0.42 112-113 kp/s...
Just tried ver. 42
hovered around 653kp/s
Still slower than the reported speed from ver.40 (reported between 699kp/s and 645kp/s averaged about 670kp/s) for me but a lot closer.
Do you know if ver. 40 might have just been reporting the speed wrong?
Also when the reported speed from ver. 40 was above about 600kp/s it would only report 645 or 699kp/s and nothing else. Was it rounding to these numbers?
Maybe ver. 42 is just a lot more accurate in reporting the speed. That would be good.
Thanks for the quick response and the hard work on proth_sieve!
Thanks. Yeah, there's definitely a bit of rounding going on. My timing routines suck at the moment... The best way to check speed is to do a decently sized range (say 50M) and then look at the
"Total time: xxx ms."
at the end. You'll want to use the same range for all tests of course.
mklasson: What would it take to get a SSE2 version for Linux? Login to a Linux-box running on a P4? I could create an account on my laptop for you if you'll send me an SSH-key, and as we are in the same timezone we could probably agree on a time where I make sure it's on the net.
If you're interested I'll PM you my email.
.Henrik
Henrik,
that would definitely work, but it may not be necessary. If you could download
http://n137.ryd.student.liu.se/TEST_...linux_sse2.tgz
or
http://n137.ryd.student.liu.se/TEST_...se2_static.tgz
and test one of them I'd be pleased to hear your results.
Mikael
I've tried the non-static version and it runs on my laptop and it runs 10-15% faster than the cmov-version.
But still only ~240kp/s on a 2GHz, it will still be better used for factoring, but it's still nice to have the choice.
I can try the static version tomorrow if it's needed.
.Henrik
I just looked at some stat files from previous ranges using ver.40 and they were all around 644kp/s so I am seeing a speed increase.
Last edited by Deoje; 02-13-2004 at 02:41 AM.
sse2.42 - 199-201 ki/s without deviations
cmov.42 - 150 drops to 100 ki/s
regular.42 - 142-136 ki/s
well nice! very stable speed!!! and speed increase is also very impressive
thank you!
666000 sieving cause such improvements =)))
and just one request
please add version number to file name.
someone want to keep few clients in a same directory.
and how about service installer???
(can't remember how many time i write this for developers)
Concerning the "count-down" feature:
It would be useful e.g. when someone has two PCs crunching on a big range. Then, he could set up one machine counting up and the other counting down. Assuming he takes care that they don't run into each other (range-wise), this wouldn't require much work.
Dunno... already had sort of this scenario two or three times. It'd be a nice-to-have feature IMHO, but I rate it low priority.
wow. I'm not alone!!! this feature indeed not high priority but very useful.
imho it's implementing not so difficult.
and it's also can be some speed increment (but also can be not).
maybe somebody can explain something about speed for up and down sieving
and sobistrator can do this job.
when it sees that two machines meed at the middle of range (assuming equal crunching rate) it add next reserved range to nextrange.txt and all starts from the beginning.
I doubt I'll implement downwards sieving -- too much hassle and too little value. Just split the range evenly if you've got two (or more) machines doing the same range. Sobistrator's even got a button that distributes a range evenly over all machines, taking their individual sieve speeds into account.
But anyhow, I've done some more tests and verified that the linux SSE2 client indeed works fine now so I've added a link to it at http://n137.ryd.student.liu.se/proth_sieve.php. (Thanks for the prodding Henrik). Any Athlon64 users sieving under linux will likely want to use it.
Oh, and as for version number in filename. Just rename it yourself. I prefer having the version number in the archive name but not in the executable name.
Mikael
Long enough.
Version number: personal preference. Easier to upgrade for one thing. Just copy over the old executable instead of having to change scripts that reference it and whatnot.
I totally agree with your decissions. As a developer, I would never do either of those things. (ie, adding a pointless, confusing feature and renaming the executable)Originally posted by mklasson
Long enough.
Version number: personal preference. Easier to upgrade for one thing. Just copy over the old executable instead of having to change scripts that reference it and whatnot.
Cheers,
Louie
so we as users must do it manually... =)))))
and there's nothing confusing about this feature
you give to proth_sieve two numbers and if first is larger than secont it starts the countdown/
btw, two factors was autosubmitted at holidays
666153670507067 | 21181*2^2106740+1
666162285968381 | 33661*2^2581920+1
666.154T 21181 2106740 6.662 Sun 22-Feb-2004 5543.673 16.65
666.079T 22699 8854534 6.661 Wed 18-Feb-2004 163195.110 16.65
well done!!!
thank you very much!!!!!!!!
Well, I think this will bring the risk of (especially an inexperienced user) to, say, input; 215300 as and 21540 (instead of 215400), and the program thinks the user wants to sieve downwards from 215300 to 21540 until the user notices something is wrong.Originally posted by Death
so we as users must do it manually... =)))))
and there's nothing confusing about this feature
you give to proth_sieve two numbers and if first is larger than secont it starts the countdown
This may sound as a silly mistake, but it might happen. We all have made various mistakes down the path. Even one of the most experienced sievers might fall into such a mistake out of carefullness.
It is for our best interest to keep the client as easy to use as possible.
PS: If there is really a benefit in downward sieving, then it is fine. But after 13 months of sieving, I do not think there is. It will only complicate things a bit more.
one thing about first time start
it look's like a (kinda, don't want ro restart running client)
but should look likeCode:Sieve from : XXXXXX Sieve to : YYYYYY
ie two extra spaces after "sieve to" and ":" to align input positions.Code:Sieve from : XXXXXX Sieve to : YYYYYY
as says Nuri
Well, I think this will bring the risk of (especially an inexperienced user) to, say, input; 215300 as and 21540 (instead of 215400)
I was just wondering if the dat file is updated every time a new factor is found or if it has been updated at all since the last K value was removed? My understanding is that it hasn't. Would it be difficult to have it automatically updated so an up to date copy can be obtained anytime? If this would be to dificult to do then no problem just say and I'll forget about it completely as I believe I've been told before removing N values makes very little difference in the speed of the siever, however this would eliminate duplicates from showing up and even a tiny speed up is a speed-up. Ohh oyu know how we DC'ers are. We love to strangle every little bit out of our limited resources.
A second side question was can the client be optimized for higher P values? I believe i heard that mentioned before. At waht point would that become reasonable, if ever?
I've been searching this forum for a discussion of the excluded factor file and haven't found it, so my apologies if I beating a dead horse....
The current PRP range is 6630284 < n < 6830284 (from MikeH's stats pages)
but in factexcl.txt I'm finding
325031458051441 | 33661*2^6912408+1
324982891732153 | 55459*2^7352074+1
324981044968207 | 67607*2^6727819+1
324964190065829 | 33661*2^6970800+1
etc.
Why are these excluded?
Oh.. OK, probably this thread
See: http://www.free-dc.org/forum/showthr...&threadid=6797
PS: dmbrubac, do you read your private messages on this forum? I have sent you one a moth ago and you still haven't readed it .