Mersenne Digest Wednesday, May 16 2001 Volume 01 : Number 853 ---------------------------------------------------------------------- Date: Tue, 15 May 2001 20:56:20 -0400 (EDT) From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? On Tue, 15 May 2001, Gareth Randall wrote: > Also, any code would be very hardware specific, and may only work if the display was not displaying, say, a desktop. > > However, if someone could implement it, it could provide the *ultimate* in Mersenne related screen savers! What you'd see on the screen would be the actual calculations themselves taking place before your eyes, and with no overheads for displaying it either! This question pops up every once in a while. A few years ago I looked through a postscript manual wondering how difficult it would be to build a postscript file that crunched RC5 keys when a printer tried to render it. The latest bleeding edge graphics cards are programmable to a limited degree (am I thinking of the ATI Radeon here?) but not nearly programmable enough, I'm sure. Heck, at least these ideas have a better chance than the guys who want to crack the programming on kids' toys to make them crunch RC5 keys :) jasonp _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 01:32:15 +0000 (GMT) From: Russel Brooks <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? John R Pierce wrote: > Virtually all GPU's in use today are fixed function hard wired graphics > accelerators. There's no way to use them for general purpose computational > use. Also, there's no APIs, and each chip vendor has a radically different > architecture. Too bad, the idea might also have given us an interesting screen saver as a side effect! :-) Cheers... Russ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 15 May 2001 20:58:34 -0500 From: "Jeramy Ross" <[EMAIL PROTECTED]> Subject: Re: Mersenne: SUMOUT errors I don't really know how much help this will be since I don't know your exact situation and am not a expert by any means, but here goes! First, the software modem may be a culprit. I have had problems with ones of the HSP variety. Most show up as 'HSP Micromodem56' or something very similar on your system. Most of these modems also use a chipset manufactured by PCTel. Fairly stable, but use a nice chunk of CPU time when online, and I have received errors when I am checking email and/or surfing the web while using this type of modem. I have no hard evidence to tie this modem to the errors, but all errors happened when I was using that modem or soon after (I hooked up a external modem just to see if the same would happen with it and I did not receive errors when using it). I have no idea if you have a modem similar to that one or not, but it may be the problem. Also, the electrical environment may be vastly different. I am assuming that where you had your computer was at school, and it is now at home. At my home, I have problems with various utility problems, and have been told by others that utility problems could cause such errors. I invested in a UPS with line conditioning to hopefully control some of those problems. Maybe one of these two things could be your problem.. I wish you the best of luck in finding and fixing the problem! - - Jeramy _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 15 May 2001 19:21:08 -0700 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? > This question pops up every once in a while. A few years ago I looked > through a postscript manual wondering how difficult it would be to build a > postscript file that crunched RC5 keys when a printer tried to render it. postscript is essentially forth, after all. Trouble is, most postscript interpreters are pretty damn slow. > The latest bleeding edge graphics cards are programmable to a limited > degree (am I thinking of the ATI Radeon here?) but not nearly programmable > enough, I'm sure. NVIDIA's chips are semi programmable too, but a big hurdle is lack of documentation on the 3D rendering engine. That stuff is trade secret. I *do* suspect you could use the geometry engine (aka "Transformation Lighting and Projection") to do large numbers of fixed point 3x3 vector-matrix dot products with limited precision rather quickly. The question is, how useful would this be? The pipeline is probably such that you load one matrix and "transform" a large number of x,y,z vectors through it at a rather high speed. I'm not sure how useful this primitive would be in doing FFT operations. The newest Geforce3 chip also has both Pixel Shaders and Vertex Shaders which are each a SIMD programmable vector processors. The Pixel Shaders operate on every pixel and generate the actual RGB pixels while the Vertex Processors operate on the geometry and texture mapping coordinates of the 3D mesh... I don't know much about these, but pixels are only 8 bits per component so the pixel processors can't be very wide. I'm also not sure how fast you can get results OUT of the nvidia memory. Typically, these cards have 32-64MB of very high speed dedicated DDR SDRAM, but its optimized for the GPU to write into the memory, and the display refresh engine to read from it, I don't know how fast results could be read back into the host system - -jrp _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 15 May 2001 19:50:25 -0700 From: Bob Margulies <[EMAIL PROTECTED]> Subject: Re: Mersenne: games one can play with imaginary sheep Paul Landon wrote: > Date: Tue, 15 May 2001 18:12:39 +0200 > From: Paul Landon <[EMAIL PROTECTED]> > Subject: Re: Mersenne: games one can play with genuine composites > [snip] > Cheers, > Paul Landon > > ps. Every train driver knows that Scottish sheep have > a maximum of 7 colours :-) > > _______________________________________ Generalization: It can be shown that the number of colours of Scottish sheep must be a Mersenne number. Therefore, the number must be 1, 3, or 7. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 15 May 2001 22:46:03 -0500 From: Ken Kriesel <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? Among others, I raised the question with George Woltman some time ago. I trust his judgment that his time is better spent elsewhere. However, I wonder if there might be some possibilities in trial factoring there. That would present the possibility of a factoring screensaver, and an FPU LLtest, running together on what is nominally a uniprocessor. Just speculation, Ken _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 00:24:47 -0500 From: Ken Kriesel <[EMAIL PROTECTED]> Subject: QA (was re: Mersenne: Purpose of the self-test; also, aren't P4s fast!) At 10:23 PM 5/15/2001 -0000, "Brian J. Beesley" <[EMAIL PROTECTED]> wrote: >On 14 May 2001, at 20:52, George Woltman wrote: >> >> >Is the self-test in fact just to check >> >that there's not something in the CPU which goes glitchy when running >> >flat-out SSE2 code for hours on end? >> >> Yes. The QA suite that Ken Kriesel and Brian Beesley worked on does a >> better job at testing edge conditions. Of course, they'll need to update that >> suite using the new limits. For the time being I would like to continue focussing our QA efforts on the general case, rather than P4's specific limits, since 1) there are relatively few P4's 2) we haven't finished QA testing in all run lengths with V19 / V20 (sign up now for a limited number of large exponents still available!) 3) the V19/20 QA now ongoing establishes "gold" residues over a huge range of exponents, against which other programs on other architectures can also be tested. .... >Actually most of the exponents in the test suite were chosen to >exercise code in a manner which is particularly hard on the "magic >numbers" involved in the collapsed DWT. Above is one of the methods of exponent selection. As George Woltman stated it: "Exponents that are close to a multiple of the FFT length." Other selection methods used to select full-LLtest exponents for QA were: 1) Already double-checked good numbers (or triple- or higher checked). Rerun to verify we can reproduce known-good results of previous versions or other code. 2) Duplicate the primality result for all known mersenne primes. (A special case of the above.) 3) The uppermost and lowest prime exponents within the determined limits for a given runlength. Always test limit cases. A little more than George suggested: "Those near the end of each range should be checked for excessive convolution error." 4) The prime exponent on either side of each integer power of two within the range supported by the program 5) Randomly selected prime exponents within the determined limits for a given runlength; typically one per higher runlength. The purpose of this set is to perhaps smoke out some case which we did not imagine. 6) We also tested a few composite exponents, just in case they behaved differently. 7) LLtests were except for #6, mostly done on exponents that had already run the gauntlet of trial factoring, p-1, and sometimes ecm. >Perhaps it would help us if George could indicate the approximate >limits for each run length when the SSE2 code is in use. Definitely. >But could I just point out that there is a _potential_ benefit in >running selftests using ridiculously small exponents for the run >length being tested. Normally the maximum permitted roundoff error is >0.4; this means that a roundoff error will only be detected as such >on one in every five occasions on which it occurs. If we use a small >exponent then we could reduce the roundoff error limit to 0.1 (or >maybe even less) and therefore detect a much larger proportion of any >roundoff errors which might occur. The fact that the residual checked >at the end of each self-test may still be correct does not prove that >a hardware glitch has not occurred, though gross errors will of >course cause the selftest to fail for this reason. If I recall correctly, this does not require "ridiculously" small exponents, since the convolution error falls off quickly away from our usual upper limit on exponent for a runlength. Convolution error varies with run length, exponent, and shift count. Running a case where we know the expected answer with high certainty: exponent, runlength, # of iterations, shiftcount? entered as qadata.txt 1279,40,1277,0,xxxxxxxxxxxxxxxx 1279,48,1277,0,xxxxxxxxxxxxxxxx 1279,56,1277,0,xxxxxxxxxxxxxxxx 1279,64,1277,0,xxxxxxxxxxxxxxxx output respectively Exp/iters: 1279/1277, res: 7653615CCA7AB4C0, maxerr: 4.000000, maxdiff: 131072.000000000/529374.103214235 Exp/iters: 1279/1277, res: 5C21BA6CB463E665, maxerr: 0.500000, maxdiff: 128.000000000/393.066381654 Exp/iters: 1279/1277, res: 0000000000000000, maxerr: 0.157410, maxdiff: 1.000000000/2.342300785 Exp/iters: 1279/1277, res: 0000000000000000, maxerr: 0.001817, maxdiff: 0.007812500/0.051145460 >Date: Fri, 07 May 1999 01:48:12 -0500 >To: George Woltman <[EMAIL PROTECTED]> >From: Ken Kriesel <[EMAIL PROTECTED]> >Subject: Re: more shift count variation qa results of 4423 > >At 09:07 AM 1999/05/06 -0400, you wrote: >>Hi Ken, >> >>At 12:29 AM 5/6/99 -0500, you wrote: >>>The cutoff at 4365 seems a little conservative; 4423 seems quite happy with >>>shift counts >>>that push it to maxerr 0.48. >> >>To me that indicates you could well run into a shift count that creates >>a maxerr > 0.50. > >You are correct; I did a baby perl script to generate big qa files, ran 4423 >through every shift count 0-999 and got: >980 of 0 residue >20 each of unique wrong residues. So the 2% probability of false negative is >not so good. Of course the program never states a maxerr>0.50; it "reflects" >the values x> 0.50 to (1-x). I think I'll try a few neighboring exponents >to get an idea of the slope of the probability of bad residues. > >M4423 run 4421 iterations with fftl 192 and shift counts 0-999 >res 000000000000000 count 980 >res 04E0C944C91F9CE count 1 >res 1B92B6C64D8C0EB count 1 >res 2489897571D4776 count 1 >res 325D0B5486FF2AA count 1 >res 3502DA8AC1D68FD count 1 >res 3B5CF6D36D0FA3E count 1 >res 3FF0055EE85448B count 1 >res 4988524F03A6A11 count 1 >res 5D11B174FA0B038 count 1 >res 69A39F63A28D9D1 count 1 >res 6A26978370C9A17 count 1 >res 9E6C0BDDC8FFBC6 count 1 >res B2385807C567EA0 count 1 >res BC35F15EF7A5CF8 count 1 >res C2C21EA69FD21DF count 1 >res C8880763EF75BCA count 1 >res CFC67D001F69E45 count 1 >res DFC640B046F7FF7 count 1 >res EA4B46F31453796 count 1 >res FC75C83945A6029 count 1 > >M4373 run 4371 iterations with fftl 192 and shift counts 1-999 >res EF677D079BEB768 count 999 > >M4391 run 4389 iterations with fftl 192 and shift counts 0-999 attempted: >res 723CFC572EAB034 count 836 >sumout !=sumin stopped the show at this point. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 08:20:25 +0100 From: "Daran" <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? - -----Original Message----- From: Gareth Randall <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 15 May 2001 23:36 Subject: Re: Mersenne: GIMPS accelerator? >Daran, > >This is an interesting piece of lateral thinking that deserves to go further >than I think it actually does. Thank you for taking me seriously. >Essentially, I'm not sure how the operations that a graphics card can >provide, such as line drawing, texture overlaying, raytraced light effects >etc, could be made to implement a LL test or FFT etc which would require >things like bit tests, conditioning branches and loops etc. What you've listed are the functions of a graphics card, each of which will have been implemented through the application of one or more primitive operations. For example, the function of mapping a set of co-ordinates in 3-space onto screen pixels will be implemented by a linear transformation, which will itself be implemented through a number of scalar multiplications. I'm wondering if it might be possible to access any of the available primitive operations without having to invoke a specific card function. AFAICS the problem requires affirmative answers to all of the following questions. 1. Can the hardware theoretically do work useful to GIMPS? 2. Could this be done efficiently enough to be worthwhile? 3. Is it possible to program the hardware to do this work? 4. Would it be possible to read the results back from the card? 5. Is the available technical documentation sufficient for a programmer to be able to implement this? 6. Would the implementation be acceptable to the user? 7. Are the prospective gains to the project worth the programming effort? I suspect the answer to 1 is yes, given how simple the requirements are for a set of primitive operations to be able to universally compute - the Turing machine and Conway's life spring to mind. But we wouldn't waste time programming a hardware Turing machine to do LL tests, even if we had one. An example of a user issue would be if the only way to program the card is to 'flash upgrade' the GPU's on-card firmware. I wouldn't be willing to do that, although I might consider installing a special GIMPS driver, so long as I could uninstall again. >Conceivably additions could be done by superimposing textures and reading >back the resulting frame buffer, but these wouldn't be 64-bit precision >additions! That's all you get with CPU integer arithmetic, but you can build longer ones out of the shorter. >Maybe some form of matrix multiplication could be done by rotating textures >before superimposing? However, I think the resulting calculation efficiency >would be very poor, and may never achieve useful precision. Could you not build an FFT out of Discrete Cosine Transforms? Or build a multiplication from DCTs in some other way? Some cards have hardware support for this. >Also, any code would be very hardware specific, and may only work if the >display was not displaying, say, a desktop. Which would hit 'prospective gains' question hard, since it would not then be useful on Windows machines. >However, if someone could implement it, it could provide the *ultimate* in >Mersenne related screen savers! What you'd see on the screen would be the >actual calculations themselves taking place before your eyes, and with no >overheads for displaying it either! That I did not think of. >Yours, >======= Gareth Randall ======= Daran G. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 08:25:28 +0100 From: "Daran" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: 26 exponents - -----Original Message----- From: Brian J. Beesley <[EMAIL PROTECTED]> To: Nathan Russell <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 15 May 2001 23:57 Subject: Re: Mersenne: Re: 26 exponents >Actually I think that there may be a perceptual problem with many new >users in that they may give up as soon as they realize that a "most >sense" assignment is going to take several weeks to complete. >Unfortunately there seems to be no easy way to fix this! I think this could be a significant problem. I'm currently 46% of the way through double-checking M6193307, and I'm expecting to complete it on 26 July. Last time I dropped bellow 90 days queued work, I requested a factorisation, just to see what the range was. I got M16065053, which I expect to complete on 6 September - nearly six weeks to do the fastest possible assignment. This doesn't bother me now - I wouldn't be bothered if it took a year or more - but when I started, I was keen to return a result. OK, you might think a slow machine like mine would be no great loss to the project, but I'm not going to have this abacus for ever. One improvement would be to credit people with work done each time they check in, instead of only when they return a result. That way they can see themselves on the producer charts more or less immediately. Another possibility would be to extend the project to search for something else - there must be many other interesting number-theoretic questions involving primes which are not currently being researched in depth, and which could benefit from a distributed approach. We already do this with factorisations which do not contribute to the search for a Mersenne prime. There must be many people who started off doing factorisations before moving on to double-checks and first-time LLs. [...] >> Perhaps clicking the 'give me the work that makes the most sense' box >> should immediately set the appearance of the others to the work that >> will be chosen, rather than simply graying them out. > >Agreed. Does the client 'know' the threshold performance level for double-checks and factorisations? If so, is it hard-coded, or does it get this information from the server? If hard-coded, then you have a problem with people continuing to use older clients which tell them that it still makes 'most sense' to do first-time checks, long after it has become more sensible to do double-checks or factorisations. Regards Brian Beesley Daran G. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 10:56:45 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? On 15 May 2001, at 18:22, Daran wrote: > GIMPS clients use the spare capacity of the primary processing resource within > any computer:- the CPU(s). But most modern PCs have another component capable > of performing rapid and sophisticated calculations:- the GPU on the graphics > accelerator. Is there any way that the GPU can be programmed to perform GIMPS > processing when otherwise not in use? There are several practical difficulties: (a) GPUs are usually 32-bit, single-precision hardware. Nothing more is needed for graphics displays. Running multiple precision arithmetic using floating-point FFT in single-precision hardware is not very effective; you need about 20 guard bits; with a single- precision manitssa being 24 bits long, you don't have very much left to work with. (b) GPUs run code from ROM. The system as a whole transfers data but not instructions from the main CPU to the GPU through the video card bus connectors. There is no easy way to change the code which runs the processor(s) on the graphics card. (c) Even if the GPU was programmable from the system, there are so many different graphics card controller architectures that writing code that would work nearly universally would involve something close to an impossible amount of effort. And graphics cards keep changing, fast! (d) Don't forget that running a LL test on a 10M exponent involves about 8 MBytes of data storage. This is not a serious problem given the amount of system memory available to most systems capable of completing a LL test on a 10M exponent in a reasonable time, but "robbing" 8 MBytes from the more limited memory available on most graphics cards might well be critical. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 10:56:45 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? On 15 May 2001, at 22:46, Ken Kriesel wrote: > Among others, I raised the question with George Woltman some time ago. > I trust his judgment that his time is better spent elsewhere. Agreed! > > However, I wonder if there might be some possibilities in trial factoring > there. > That would present the possibility of a factoring screensaver, and an FPU > LLtest, running together on what is nominally a uniprocessor. > > Just speculation, Nice idea (using the fact that trial factoring & screensaver would be almost pure integer work, whereas LL testing is almost pure FP) but with practical difficulties. (1) To get any benefit, you're going to have to bind all that functionality into one thread - because if you are running more than one thread, the OS will schedule the threads independently, throwing away any benefit which might be gained by parallelism. (2) I think there would be serious difficulties in coordinating code between LL testing (time per iteration almost constant, of the order of tens of millions of CPU cycles) & trial factoring (time per candidate very variable, and of the order of hundreds of CPU cycles). I've no idea at all as to how you would usefully squeeze in a screensaver too, but I do think that the code coordination neccessary to parallelize tasks in a single process thread would be very hard to achieve. (3) Though trial factoring places almost no load on the system memory bus or the floating-point execution units, there are other potential bottlenecks within the CPU - in particular, the L1 instruction cache, instruction decoders, instruction pipelines, jump prediction tables & "spare" registers (required for out-of-order execution) - which may well limit severely the amount of factoring work which could be done in parallel with LL testing, without inflicting a significant performance penalty on LL testing. Given that trial factoring is well advanced, implementing a scheme which increases the trial factoring throughput of the project as a whole at the expense of LL testing throughput does not seem to be a good idea. However, if anyone can provide the functionality that Ken suggests without impacting LL testing performance noticeably, I'll be just as grateful as everyone else! Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 10:56:45 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: 26 exponents On 15 May 2001, at 22:36, Steinar H. Gunderson wrote: > On Tue, May 15, 2001 at 04:48:19PM +0100, Daran wrote: > >BTW what happens now when a first-time check, (or for that matter, if a > >double-check) discovers a new prime. Surely this is checked immediately on > >the fastest machine available to the project, and not left to the vagaries of > >random allocation? > > It is run on a different architecture, with different software. The > three first were (as far as I know) tested on Crays, Through the good offices of David Slowinski. > while the 4th (M38 > (we think)) was tested on an Alpha machine with mlucas, as far as I > remember. Yes. DS couldn't help, for some reason, probably due to Cray having been bought out by Silicon Graphics. > > The idea is to completely eliminate any possibility of a persistent > program or hardware bug :-) Plus, Prime95 didn't have the random shift code which allows it to check its own results until after M37 was discovered; and the random shift code was rather new when M38(?) was discovered. Another point - we're coming up to the second anniversary of the discovery of M38(?) - I think we're overdue to find another one! Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 13:51:09 +0200 From: Alexander Kruppa <[EMAIL PROTECTED]> Subject: Re: Mersenne: ECM Question... Eric Hahn wrote: > > If a person runs an ECM test using a B1 of 250,000 with 700 > curves (for up to 30 digits), will they also find any factors > that they would have found if they had used a B1 of 50,000 with > 300 curves (for up to 25 digits) ?!? > > Eric If the sigma is the same, then a curve with B1=250000 will find any factor that a curve with B1=50000 finds. When you run 700 random curves at B1=250000, you might theoretically miss a factor that someone else finds with B1=50000, if he gets a lucky sigma so that the group order is very smooth. But in general, using the same number of curves, the higher bound should find all the factors that the lower bound can find. But dont be tempted into running only a few curves at very high bounds. The strength of ECM is that you can try curves with different group orders until a sufficiently smooth one comes along. So "skipping" bound levels is usually not a good idea unless you have reason to believe the the number unter attack has only large factors which call for a higher bound. Ciao, Alex. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 13:57:04 +0200 From: Alexander Kruppa <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS accelerator? John R Pierce wrote: > The newest Geforce3 chip also has both Pixel Shaders and Vertex Shaders > which are each a SIMD programmable vector processors. The Pixel Shaders > operate on every pixel and generate the actual RGB pixels while the Vertex > Processors operate on the geometry and texture mapping coordinates of the 3D > mesh... I don't know much about these, but pixels are only 8 bits per > component so the pixel processors can't be very wide. Could this help NFS sieving? Ciao, Alex. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 10:22:27 -0500 From: "Steve" <[EMAIL PROTECTED]> Subject: Re: Mersenne: SUMOUT errors For what it's worth, I have had the exact same problem getting illegal sumouts when using the modem on this 475Mhz K6 PC. Hasn't happened since january but had been happening about once a fortnight for months, and _only_ when the modem was heavily in use (Rockwell HCF 56K Data Fax PCI Modem). I had forgotten all about it until I read Jeramy's message. It has never happened on any of my other PCs. Oddly enough, I have noticed on Athlons that the iterations run about 2% faster when the modem is connected! Steve Harris - -----Original Message----- From: Jeramy Ross Date: Tuesday, May 15, 2001 9:24 PM Subject: Re: Mersenne: SUMOUT errors >I don't really know how much help this will be since I don't know your exact >situation and am not a expert by any means, but here goes! > >First, the software modem may be a culprit. I have had problems with ones >of the HSP variety. Most show up as 'HSP Micromodem56' or something very >similar on your system. Most of these modems also use a chipset >manufactured by PCTel. Fairly stable, but use a nice chunk of CPU time when >online, and I have received errors when I am checking email and/or surfing >the web while using this type of modem. I have no hard evidence to tie this >modem to the errors, but all errors happened when I was using that modem or >soon after (I hooked up a external modem just to see if the same would >happen with it and I did not receive errors when using it). I have no idea >if you have a modem similar to that one or not, but it may be the problem. > >Also, the electrical environment may be vastly different. I am assuming >that where you had your computer was at school, and it is now at home. At >my home, I have problems with various utility problems, and have been told >by others that utility problems could cause such errors. I invested in a >UPS with line conditioning to hopefully control some of those problems. >Maybe one of these two things could be your problem.. I wish you the best of >luck in finding and fixing the problem! > >- Jeramy > _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 10:52:41 -0500 From: fay aron charles <[EMAIL PROTECTED]> Subject: Mersenne: Newsgroup formation? > On Tue, May 15, 2001 at 10:23:33PM -0000, Brian J. Beesley wrote: > >If you understand _nothing_ discussed on a mailing list, there's no > >point in subscribing. Similarly if you understand _everything_. You > >can always delete the messages which you consider beyond your > >intellect, or beneath contempt. Personally I like the range we have > >at present. > > Yes -- that is my opinion too. I skim quite a lot, though ;-) Personally, I really hate all mailing lists. I was on one once where somebody misused the system, and everybody (at once) complained by emailing a complaint about the post to the base address. Pretty soon people started complaining about the complaints, saying the "huge traffic could be avoided if you had never complaind." Before long, someone thought it would be funny to send a 3MB attachment to everyone, and soon others followed. Now, I know the intellegence level here is __much__ higher, but I didn't join for almost 2 years, because of my hatred of such groups. I'm sure this format is keeping many people away (especially the more experienced netizens). It seems a newsgroup is such a better medium for discussions like this. Then, if I go on vacation for a month, I won't have to unsubscribe to keep my INBOX from overflowing. Also, a newsgroup will allow newbies to read through old posts and see what types of question are asked. This is really the only way to keep the same questions from being asked over and over. But, most of all, I want threading. If I have a K7 processor (I do), I might not want to read about every bugfix in v.21, because it isn't going to affect me. The ability to skip threads is extremely powerful. Oh, and did I mention that keeping my own archive of messages is really eating my disk space? Instead of 50 people saving the same message to read later, it should just be kept on a newsgroup server, so that if I need to refer to it later, I just download it again. -aron _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 12:22:00 -0500 From: "Ryan M McGarry" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Newsgruop formation? I'm sure many of us on this mailing list are familiar with Slashdot, and that the code behind it is open-source (known as Slashcode). For those of us who aren't, Slashdot (http://www.slashdot.org) is a news website which covers news mainly in the interest of the Open Source community. About 10 of the latest news items are posted on the front page, and each has a related discussion board automatically set up. I propose that someone could implement and host our mailing list on this website... This could allow for people to browse through threads easily, and allow people to catch up easily when joining for the first time, or coming back from vacation. The obvious problem to me is that the creation of new threads is normally done manually, with only the most interesting/serious topics being posted. We won't be having hundreds of posts every day, but somebody (or some group of us) will have to make sure that whenever anybody requests a post, that it gets posted after meeting some criteria... In my opinion, the quality of some of the discussions on this mailing list should be available to the public without having to subscribe to the mailing list. And this type of system will allow anonymous people to post, maybe with valid points... Just my two cents... Ryan McGarry _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 11:42:22 -0700 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Newsgruop formation? > I'm sure many of us on this mailing list are familiar with Slashdot, and > that the code behind it is open-source (known as Slashcode). we've had 600 messages TOTAL since the beginning of the year. Thats like 3-4 a DAY average. SlashDuh type web forums thrive on communities of 1000s of messages a month. And look at the quality of the average postings on slashduh... mostly cheap and easy microsoft bashing. quite frankly, I detest web forums for this sort of thing. If we had 10X the traffic we have, I'd consider the newsgroup thing, otherwise, a mail list is just FINE. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 19:02:17 -0500 From: Ken Kriesel <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: 26 exponents I believe that is set at the server. Ken At 08:25 AM 5/16/2001 +0100, "Daran" <[EMAIL PROTECTED]> wrote: >Does the client 'know' the threshold performance level for double-checks and >factorisations? If so, is it hard-coded, or does it get this information from >the server? If hard-coded, then you have a problem with people continuing to >use older clients which tell them that it still makes 'most sense' to do >first-time checks, long after it has become more sensible to do double-checks >or factorisations. > > >Daran G. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 16 May 2001 19:16:06 -0500 From: Ken Kriesel <[EMAIL PROTECTED]> Subject: Re: QA (was re: Mersenne: Purpose of the self-test; also, aren't P4s fast!) At 10:56 AM 5/16/2001 -0000, Brian Beesley wrote: >On 16 May 2001, at 0:24, Ken Kriesel wrote: > >> For the time being I would like to continue focussing our QA efforts on the >> general case, rather than P4's specific limits, since > >Agreed. I was talking about the "short" test suite, where the runs >stop after 400 iterations. We can generate the required data for a >large number of exponents without diverting significant effort. In >fact it's much easier to do this than it was a couple of years ago, >as we have at least two reasonably efficient programs other than >Prime95 which can be used to generate & cross-check the data. >> >> If I recall correctly, this does not require "ridiculously" small exponents, >> since the convolution error falls off quickly away from our usual upper >> limit on exponent for a runlength. > >Quite correct. IMO it is "ridiculous" to run a whole LL test using a >FFT run length of 2R when a run length of R would suffice; but >running at least some 400-iteration short tests with a "half size" >exponent during a self-test does make sense in two ways: it saves >having to generate quite as much short run data (since we can recycle >some of the smaller exponents into larger self-test run lengths), and >- providing there is a temporary reduction in the rounding error >limit whilst these short runs are in progress - we would be making >the self-test more stringent. Yes. Even the next-longer runlength provides a very large drop in the expected convolution error for those exponents near the limit of a runlength.(orders of magnitude.) Two to one on runlength is not needed. The ratio 5:4 gives substantial reductions. >There is no point in optimizing the self-test for speed, since we are >going to run the self-test for a fixed period of time. There is some point in having the self-test resemble closely, actual running conditions, to be as valid a test as possible, with respect to everything from bit patterns to power loadings. Ken _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ End of Mersenne Digest V1 #853 ******************************
