Re: Mersenne: Hyper-threading
Look towards the end of this thread for benchmarks with LL and factoring on one processor via hyperthreading... http://www.teamprimerib.com/gimps/viewtopic.php?t=8 Mike (Xyzzy) _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Hyper-threading
On Saturday 21 September 2002 21:20, Daran wrote: > Could this feature of forthcoming Intel processors be used to do trial > factorisation without adversely impacting upon a simultaneous LL? Could > this be easily implemented? 1) _Existing_ Pentium 4 Xeons have hyperthreading capability. 2) Implementation is easy; just run two processes - one LL & one TF - assigning one to each virtual processor. In fact there's no other way to implement: you can't have one process running in multiple virtual processors simultaneously with hyperthreading technology alone. 3) I reckon there would be a very significant performance hit. Temporary registers, instruction decoders etc. are shared so any pressure whatsoever on the "critical path" would cause a performance drop - even if the code in the two processes could be guaranteed to stay phase locked so that there was no simultaneous call on a particular execution unit. (In practise I think unregulated phase drifts would result in a phase locked clash, since this appears to be the most stable state). You would probably get 20-30% more _total_ throughput this way than you would be running LL & DC assignments in series, i.e. the LL test speed would be at best 2/3 of what it would be without TF running in parallel on the same CPU. One benefit of hyperthreading technology for compute-bound processes in an interactive environment - provided you're running only one compute-bound process per _physical_ processor - is that the extra capacity helps the system to react more quickly to interactive loads, so it's a lot less likely that foreground users will notice the background CPU load. Regards Brian Beesley _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: TF - an easy way to cheat
On Saturday 21 September 2002 16:15, Daran wrote: > > > ... through 64 bits the algorithm runs much faster than it does for 65 > > bits > > > and above. The factor is around 1.6 rather than 2. > > Good point, and one which I didn't consider in my reply. But the ratio > must be different for the P4, which uses SSE2 code for factorisation over > 64 bits. Pass, I haven't let my one & only P4 system do any TF! > > > According to undoc.txt:- "You can limit how far the program tries to factor > a number. This feature should not be used with the Primenet server.", > which implies that something bad will happen if you do. Umm. I guess there is a possibility that PrimeNet might get confused about whether an assignment is completed (as far as the system running it is going to go). > > > Suggestion: the TF savefile should be modified to contain an internal > > consistency check (say the MD5 checksum of the decimal expansion of the > > current factoring position) so that cheating by editing the savefile, > > causing > > > "jumping" past a large range of possible factors, would be made a great > > deal > > > more difficult. > > Easily cracked. Why not just encrypt it? True. But the problem with encryption is that it has to be decrypted - if the client knows how to do that (& it has to, if the save file is to be any use at all) then a cheat can dig out the code somehow. One thing that could be done is to write an extra "hidden" save file (or store a registry key) containing some value computed from the save file contents, so that if the save file was manually changed there would be a clash & the client would know something odd had happened. Another trick (which I actually used in a now-obsolete anti-tamper system) is to take the time the file is opened for writing (in unix seconds) & xor that into part of the file data. When checking the file, read the file creation date from the directory, xor into the data, if the file checksum fails increment the creation date & try again - at most 10 times, since the file creation date (stored in the directory) shouldn't disagree with the system clock read by your program just before it called the file open routine by very much. This works pretty well because few people will twig what you're doing (even if you document it!) & even fewer will manage to frig the checksum properly. The idea here is to make "successful cheating" not worth the effort. There's no way it's going to be possible to stamp it out altogether. Personally I'm more concerned about the possibility of cheating your way up the PrimeNet LL testing league table. The obvious way to do this is to start a test, stop manually after a minute or two, edit the iteration number to a few less than the exponent & restart ... lo & behold, you _could_ "complete" LL tests on _any_ exponent in about five minutes, even on a P90 system. The fact that the residuals would all be wrong is irrelevant since PrimeNet doesn't penalise bad results; in any case, you'd probably get away with it until DC started to catch up with you. An internal consistency check would make this a lot harder to do. MD5 is pretty good (though not perfect) as there is no "simple" way to fudge it; the compute effort involved in frigging a file to achieve a specified MD5 sum is several orders of magnitude greater than that required to LL test a 10 million digit exponent, so it's simply not worth trying. Regards Brian Beesley _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Hyper-threading
Daran wrote: > Could this feature of forthcoming Intel processors be used to do > trial factorisation without adversely impacting upon a simultaneous > LL? This was discussed in March, starting in Digest Number 945. Short answer: no. Medium answer: If an application were not already optimized for maximum pipelining, hyperthreading would allow another application to use unused pipeline capacity. But Prime95 is already so optimized. Richard Woods _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
SV: Mersenne: TF - an easy way to cheat
That's not what Nathan meant, and it would have the opposite effect of what Torban wants, which is to guarantee that he never LLs an exponent which has not had a full factorisation effort. Your are truly right, Daran. But my name is Torben. And not Torban. Torben means the the bones of the great god THOR. This god is responsible for the ligthning. And is next to the superior god ODIN. :-) One advantage of this, from Torban's POV, is that his chance of finding a factor through P-1 is *increased* if it has not been properly TFed. What is POV? br tsc _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Hyper-threading
Could this feature of forthcoming Intel processors be used to do trial factorisation without adversely impacting upon a simultaneous LL? Could this be easily implemented? Regards Daran G. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: TF - an easy way to cheat
- Original Message - From: "Jacek Kolonko" <[EMAIL PROTECTED]> To: "GIMPS" <[EMAIL PROTECTED]> Sent: Saturday, September 21, 2002 5:38 PM Subject: RE: Mersenne: TF - an easy way to cheat > > >One way to avoid this disappointment personally would be to focus > solely > > >upon TF or > > >P-1. > > > > To the best of my knowledge, there is no way in my version (22.8.1) to > > set the client to do only P-1. > > > > Read undoc.txt in your Prime95 directory: > > You can force prime95 to skip the trial factoring step prior to > running a Lucas-Lehmer test. In prime.ini add this line: > SkipTrialFactoring=1 That's not what Nathan meant, and it would have the opposite effect of what Torban wants, which is to guarantee that he never LLs an exponent which has not had a full factorisation effort. Nathan is correct that the client can't be set only to do P-1. I achieve this effect by setting SequentialWorkToDo=0, and by ensuring that it never runs out of exponents to P-1. This requires continual hands-on management, collecting new exponents, and unreserving completed ones. One advantage of this, from Torban's POV, is that his chance of finding a factor through P-1 is *increased* if it has not been properly TFed. >Jacek Kolonko Daran G. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: TF - an easy way to cheat
- Original Message - From: "Brian J. Beesley" <[EMAIL PROTECTED]> To: "Torben Schlüntz" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, September 21, 2002 8:51 AM Subject: Re: Mersenne: TF - an easy way to cheat > On Friday 20 September 2002 22:42, Torben Schlüntz wrote: > > Anyone receiving a TF task could edit the worktodo.ini from > > Factor=20.abc.def,59 > > to > > Factor=20.abc.def,65 > > He would receive approx. twice the credit the effort is worth. > > Not quite - even allowing for the 1/2^6 effort involved in TF through 59 bits > ... through 64 bits the algorithm runs much faster than it does for 65 bits > and above. The factor is around 1.6 rather than 2. Good point, and one which I didn't consider in my reply. But the ratio must be different for the P4, which uses SSE2 code for factorisation over 64 bits. > Suggestion: TF should report completion of each "bit" to PrimeNet, not just > the on completion to the target depth. I don't see how this would require > changes to the server, though there would be a (relatively small) increase in > load. According to undoc.txt:- "You can limit how far the program tries to factor a number. This feature should not be used with the Primenet server.", which implies that something bad will happen if you do. > Suggestion: the TF savefile should be modified to contain an internal > consistency check (say the MD5 checksum of the decimal expansion of the > current factoring position) so that cheating by editing the savefile, causing > "jumping" past a large range of possible factors, would be made a great deal > more difficult. Easily cracked. Why not just encrypt it? > Regards > Brian Beesley Daran G. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: TF - an easy way to cheat
> >One way to avoid this disappointment personally would be to focus solely > >upon TF or > >P-1. > > To the best of my knowledge, there is no way in my version (22.8.1) to > set the client to do only P-1. > Read undoc.txt in your Prime95 directory: You can force prime95 to skip the trial factoring step prior to running a Lucas-Lehmer test. In prime.ini add this line: SkipTrialFactoring=1 Jacek Kolonko smime.p7s Description: application/pkcs7-signature
Re: Mersenne: TF - an easy way to cheat
On Sat, 21 Sep 2002 16:33:04 +0100, Daran wrote: >One way to avoid this disappointment personally would be to focus solely >upon TF or >P-1. To the best of my knowledge, there is no way in my version (22.8.1) to set the client to do only P-1. Nathan _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: TF - an easy way to cheat
> Anyone receiving a TF task could edit the worktodo.ini from > Factor=20.abc.def,59 > to > Factor=20.abc.def,65 > He would receive approx. twice the credit the effort is worth. In fact the probability of finding a factor would be less than one sixth. [...] > Would this cheat be trapped later by P-1 or does P-1 trust earlier work > so factors below say 67-bits are not considered? P-1 doesn't 'trust' the amount of TF, in the sense of failing to find (or ignoring) small factors. However the calculation of the probability of success - and hence of the optimal bounds - assumes that none will be found. P-1 and TF search different but overlapping factor spaces. My understanding is that P-1 has about a 1 in 3 chance of finding a factor in the TF range. However I don't think the server logs who finds a factor, or how it was found, or even if the exponent was assigned to the finder. > The above questions are _not_ asked because I intend to use the method. > :-/ I think it would miscredit GIMPS as we trust the results of GIMPS. Factorisation is merely a tool for quickly eliminating candidates. We do not double check negative results as a proof that there are no factors in the checked range (though found factors are checked by the server itself). > And I would be disappointed if I learned that an LL I did could have > been solved far earlier - and using less effort. One way to avoid this disappointment personally would be to focus solely upon TF or P-1. > br tsc Daran G. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: TF - an easy way to cheat
On Friday 20 September 2002 22:42, Torben Schlüntz wrote: > Anyone receiving a TF task could edit the worktodo.ini from > Factor=20.abc.def,59 > to > Factor=20.abc.def,65 > He would receive approx. twice the credit the effort is worth. Not quite - even allowing for the 1/2^6 effort involved in TF through 59 bits ... through 64 bits the algorithm runs much faster than it does for 65 bits and above. The factor is around 1.6 rather than 2. > Ofcourse nobody would do this, as we are all volunteers! Or could > somebody some day be tempted to raise his rank using this method? Never underestimate what some people may do to rig league tables! > Does GIMPS hold some log for TF's done by which account? If so could > this log please be open? I think the log exists but, since intermediate checkpoints are not logged, it might not show anything. > Would this cheat be trapped later by P-1 or does P-1 trust earlier work > so factors below say 67-bits are not considered? P-1 doesn't care what (if any) TF has been done previously. _Some_ but by no means all "missed" factors would be picked up bt P-1. Note also that some factors may be missed due to genuine "glitches" as opposed to deliberate skipping. > The above questions are _not_ asked because I intend to use the method. > > :-/ I think it would miscredit GIMPS as we trust the results of GIMPS. > > And I would be disappointed if I learned that an LL I did could have > been solved far earlier - and using less effort. Yes - but as TF is primarily designed to reduce LL testing effort, missed factors are an inefficiency rather than a serious problem. Suggestion: TF should report completion of each "bit" to PrimeNet, not just the on completion to the target depth. I don't see how this would require changes to the server, though there would be a (relatively small) increase in load. Suggestion: the TF savefile should be modified to contain an internal consistency check (say the MD5 checksum of the decimal expansion of the current factoring position) so that cheating by editing the savefile, causing "jumping" past a large range of possible factors, would be made a great deal more difficult. Regards Brian Beesley _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
