Run Windows update so your machine can download the .net update and upgrade from MFC70.dll to MFC71.DLLOk the problem as on my end but i have a new one. The sobinstrator says when i try to open it this application failed to start because MFC71.DLL was not found. Re-installing the application may fix this problem. Obviously that didn't help. Anyone know what i need to do?
Cheers,
Lee
Mystwalker,
>Just thought about it... When it's possible to set the output file names via parameters (or maybe a parameter so that the files get an infix according to the range), then one should be able to run one copy multiple times in parallel, right?
Yeah, I don't see why not. You want that?
Soo, what's this SobSieveServer of yours?
Mikael
Sure.Originally posted by mklasson
Yeah, I don't see why not. You want that?
Mikael
Well, basically it's a server storing and assigning ranges to clients and accepting found factors and notifications of completed ranges.Originally posted by mklasson
Soo, what's this SobSieveServer of yours?
Mikael
It was part of a seminar project and works with SobSieve (getting it to work with proth_sieve should be fairly easy, though).
There's still some issue, but I'm not sure whether it's program or computer related...
Hm, I think we could figure it out if someone could run the server on his/her computer. It's written in Java...
edit:
As it's been a while since we discussed excluded factors...
Are they of any worth submitting/storing?
Last edited by Mystwalker; 09-05-2003 at 10:05 AM.
Well, one question concerning proth_sieve:
Assuming one runs that program, and meanwhile copies the factors out of the fact.txt and deletes that file afterwards. Will that result in proth_sieve not saving factors anymore?
I now have a ~11G hole, which seems to happen sometimes with this ranges this high, but I just want to make sure...
> Assuming one runs that program, and meanwhile copies the factors out of the fact.txt and deletes that file afterwards. Will that result in proth_sieve not saving factors anymore?
No, no problem at all, it just creates a new file. I only wish 11G holes weren't so common...
I can't personally see any worth in excluded factors, btw.
Mikael
According to chvo, they will be the average once we hit 200T - and thanks to your work, we will a lot sooner than it seemed only weeks ago.Originally posted by mklasson
I only wish 11G holes weren't so common...
Mikael
thanks for everyones work on the new clients...damn we have come a long way.
With the new proth sieve..i saw an increase of roughly 20%.
Great Job to all involved.
Slatz
Ok, that client found a factor again - it was just a 23G hole.
It took only 1.6G to find the next one, though. Damn variance!
What a pity. I have thousands of them - literally!I can't personally see any worth in excluded factors, btw.
From the other thread:
According to my calculations (approx. 37.25G left), we need 3.45 Mp/sec.Originally posted by Keroberts1
100 T by new year we can do it!!!
I think that's achievable.
I just put up a new proth_sieve v0.37. There was a bug in v0.36 that could cause it to miss factors (something like 1 in 400 factors). I'm very, very, very sorry about that.I used to sieve 257 ranges with known factors before every release and verify that all were found, but apparently this bug slipped through anyway. I'm now verifying 834 ranges prior to release to make such errors less likely. Note that the bug only exists in v0.36 and not in earlier versions, so hopefully _very_ few factors have been missed because of this.
*** Please upgrade your version immediately. *** As a small bonus, v0.37 is about 1% faster on my athlons.
There's also a new feature that Mystwalker requested in this one. Use the "-n <id>" argument to append <id> to the basename of all filenames. If <id> is 001 then SoBStatus.dat becomes SoBStatus001.dat, and so on. "-s <filename>" can still be used to override the sob.dat filename, and takes precedence over -n.
http://n137.ryd.student.liu.se/sob.php
Regards,
Mikael
p = 86584680240941 @ 437kp/s
p = 86584690240963 @ 4294967087kp/s
p = 86584700241031 @ 437kp/s
Wow that is a speed increase Any idea what causs this bug?
Seems to work without a glitch. thx-a-lot!There's also a new feature that Mystwalker requested in this one. Use the "-n <id>" argument to append <id> to the basename of all filenames. If <id> is 001 then SoBStatus.dat becomes SoBStatus001.dat, and so on. "-s <filename>" can still be used to override the sob.dat filename, and takes precedence over -n.
btw.:
~3% speed increase with P3/win32
<1% speed increase with P3/Linux
Last edited by Mystwalker; 09-09-2003 at 05:41 AM.
from 84 kp/s to 107kp/s on a P3 450 with NT
using 037cmov instead of 036cmov
Ooookay. That sounds a bit odd to me, but, aaah, congratulations!from 84 kp/s to 107kp/s on a P3 450 with NT
using 037cmov instead of 036cmov
Keroberts1,
just enjoy your new blazing speed.
Mikael
>>from 84 kp/s to 107kp/s on a P3 450 with NT
>>using 037cmov instead of 036cmov
>Are you sure you haven't changed anything else?
Hello!
I am at 99kp/s with my celeron 410 with w98 (cmov037) so 107kp/s at 450 Mhz seems ok....
I was at 68kp/s with version 033 > more than 40% speed gain...Thanks Mikael!!!
Philippe
PS: maybe will my cpu break the 100kp/s speed with proth_sieve 0.38????
Speed 'tip': proth_sieve went from 400kp/s to 320kp/s on my AMD 1.33GHz when I enabled Windows update. It went back to 400 when I disabled it again.
btw, I'm sieving low range only.
FYI,
My Athlon 700 went from ~120 kp/s with SoBSieve 1.34 to 195 kp/s with proth_sieve_cmov_036 to 201 kp/s with proth_sieve_037_win_cmov.
Seems like only a few months ago that 60 kp/s was blazing -- oh, wait; that was a few months ago... Fantastic work by all. I hope someone writes a paper on the overall development efforts, as I'd be intested in reading it.
Mikael,
could you state what's the complexity of the used algorithm concerning the range n?
You said it's not as relevant as SoBsieve. This piece of info could be useful if we discuss about changing ranges to increase sieving rate...
Could you please explain "Windows update"?Originally posted by larsivi
Speed 'tip': proth_sieve went from 400kp/s to 320kp/s on my AMD 1.33GHz when I enabled Windows update. It went back to 400 when I disabled it again.
btw, I'm sieving low range only.
Joe O
Yes, of course. Sorry. Windows Update is a service that is available in (at least) WinXP. It seems to continiously search MS' pages for updates to relevant software, mostly security updates and such.Could you please explain "Windows update"?
I suppose that giving proth_sieve a higher priority might decrease the slowdown, but I haven't tried that.
Just got a possible bug report:
The nextrange feature seems not to work on one of my machines running proth_sieve 0.37 on Win2k.
Mystwalker,
the complexity of the Silver-Pohlig-Hellman discrete log algorithm is O(sqrt(q)), where q is the biggest prime factor of p-1. That gives you the full DL though, which we're not really interested in. The beauty of the SPH is that we calculate the DL mod q_i for each prime divisor (not necessarily unique -- you get it mod q_i^2 the second time, and so on), so we can stop when we know enough. The individual residues mod q_i are recombined using the chinese remainder theorem to get the DL mod m = product(q_i). We never need to go further than m = n_high (20M) for example. Occasionally we do so anyway because that's the most efficient procedure given the factor layout of that particular p-1. This is the source of the really far out outside-range factors. After we have calculated a suitably large m we turn to the regular Shanks baby-steps/giant-steps on the interval (n_high - n_low)/m, which is O(sqrt((n_high - n_low)/m)).
Anyhow, the net result of all this is that the complexity is a bit harder to estimate... Yes, it still depends on the n range, but how? Several different n ranges will have the same optimal work for many p, and the amount of work for a fixed range varies wildly with different p.
Oh, and about the nextrange feature, you haven't just misspelled the filename and made it next_range.txt or written pmin twice or something like that?
Mikael
I'm quite sure it didn't misspelled the file name. Anyway, a recent recheck showed the feature indeed does work. I don't know what went wrong this morning, but maybe there was a mistake on my side.
If the problem occured again, I'll tell you...
Hi all,
I haven't been receiving notification of updates for some reason, so I haven't been here for a while, but I have just subscribed to the thread again. However let me say here my thanks to Mikael for his great work in finding the Silver-Pohlig-Hellman disrete log algorithm and for coding it up. The program is remarkably fast... good job Mikael upped the limit to 2^50 from 2^48
Regards,
Paul.
what do yo umean by upped the limit. Was the limit of the previous sieve client 2^48. That will be an issue s oI'm glad that it was upped. We'll probably be breaking the 2^48 limit before the end of next summer at this rate.
One side question unrelated: Is the Siever's performance related at all to the size of the numbers being sieved? Could the performance change as we get to higher numbers or could it be optimized for larger numbers as we get dow nthe line. I'm not sure what type of algorithim is used in the program so I would not have any idea how ot even guess whether or not this is possible.
Last edited by Keroberts1; 09-12-2003 at 02:15 AM.
Just wondering, is this useful for the regular NewPgen too?However let me say here my thanks to Mikael for his great work in finding the Silver-Pohlig-Hellman disrete log algorithm and for coding it up. The program is remarkably fast
Yes, you have to calculate bigger powers as p (and the order of 2 in Z_p) increases. The overall rate doesn't seem terribly affected though -- the effect is offset somewhat by the diminishing density of the primes. But yes, the real performance is affected to some degree. It might be possible to tailor the program a bit to suit bigger numbers better, but probably no major change. Lots of vague words here. I'm assuming p stays below 2^64 here... "We'll never sieve that far anyway".Is the Siever's performance related at all to the size of the numbers being sieved?
I'm thining about this for the distant future. As I see it we will be bringing some of these numbers probably far past the 20-million mark andchances are some may go much farther than that needing PRP tests that may take months or even up ot a year. once we get to that point a single factor found every few weeks would still be extremely useful. With this outlook the sieving effort may find it useful ot go much deeper than previously thought
Hello, concerning the version 036 bug,because I didn't want to miss a factor , I have sieving twice a 10 G range with cmov 036 and cmov 037. The results, 80 factors found including duplicates and excluded, are the same with both versions. So, in "real" sieving conditions, the error rate of the version 036 seems small too...
Other trials confirming it ?
Will the Siever sieve any faster once one of the K values have been removed? Once again this is a kinda pointless question escept i was just wondering is factor finding will dropp off suddenly if we find a few primes.
Yes. How much depends on which k is killed.Originally posted by Keroberts1
Will the Siever sieve any faster once one of the K values have been removed? Once again this is a kinda pointless question escept i was just wondering is factor finding will dropp off suddenly if we find a few primes.
perhaps Sieving for only certain Ks may be benefitial once we get to the higher ranges. If that would still yeild a beneficial ratio then there is reason to think about that
It's more efficient to sieve all K's at the same time. Thats why program's were created to do that.
Sieving only one K will allow sieving much deeper for only that K in the same time, but it will cost more time to sieve all K's seperately compared to sieving them all at once.
Anyone any idea how much more efficient sieving all k's at the same time is?
I've gotten an incredible boost in factor density just in the last few G I've been sieving. Not enough to be alarmed at but it is interesting and perhaps more evidence that there is some sort of pattern causeing them to group together.
Here are the factors
86806006665839 | 10223*2^13321541+1
86808425787089 | 33661*2^5661816+1
86812209123841 | 10223*2^14637101+1
starts getting interesting **************
86822005490767 | 21181*2^13538660+1
86822396416597 | 10223*2^15637277+1
86823040551029 | 55459*2^14422258+1
86823909625963 | 28433*2^15145945+1
86824201083779 | 21181*2^12366764+1
86825582367299 | 33661*2^16773792+1
86825821343039 | 21181*2^16424444+1
sobistrator bug?
I had a few new factors which I tried to submit. Since seventeenorbust.com was down, the submit failed and I got a message about submitting the factors manually. Fair enough, but the factors disappeared from the "New factors" panel, while stilll saying that there were 8 new factors. I guess I can find the factors in the log, but I got a feeling that this behavior isn't intended.
larsivi,
you'll probably see your new factors again if you press refresh.
I'm not sure, but I think I fixed that some time ago... At least I don't have the same problem in the version I'm running. Just hadn't released it yet.
Try http://n137.ryd.student.liu.se/sobistrator_114.zip
Mikael
mklasson:
They came back with the refresh, but with the new version they didn't disappear at all.
Tjänare!
something i noticed : if i start proth_sieve_cmov.exe by adding it to the windows/current version/run in registry it does not seem to look for the SoBstatus file as it just prompts me what values i want to sieve.
when i load it it startup by adding it in the Start Menu Startup submenu it works without that problem. tried both methods with same directory , same sobstatus , together and apart.
:shocked:
Win XP SP 1
AMD XP +2000 (getting 400 kps)
512 MB RAM
Maybe there's no working directory set when you use the registry.
Just try using the -s parameter...
that didn't solve the issue
Posting Permissions
Reply With Quote