Re: Mersenne: P4 arrives!
At 09:03 PM 12/1/2000 -0500, George Woltman wrote: Dell came through and shipped ahead of schedule. Unfortunately I >was not able to upgrade the PC600 memory to PC800. The first benchmarks >are in. >You can find them at http://www.mersenne.org/bench.htm The 1.4 GHz P4 is >about as >fast as an 850 MHz Athlon or a 1200 MHz P-III. Not very impressive for the P4. I'm planning to get a new computer next year, and this strongly influences my choice. +-+ | Jud McCranie| | | | Programming Achieved with Structure, Clarity, And Logic | +-+ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: P4 arrives!
Hi all, Dell came through and shipped ahead of schedule. Unfortunately I was not able to upgrade the PC600 memory to PC800. The first benchmarks are in. You can find them at http://www.mersenne.org/bench.htm The 1.4 GHz P4 is about as fast as an 850 MHz Athlon or a 1200 MHz P-III. I'll keep everyone posted on improvements as development proceeds. Regards, George _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Glucas v.2.0 released
Guillermo Ballester Valor wrote: > There are still no precompiled binaries. I think soon will be binaries > for Alpha-Osf (ev56, ev6). Thus, you have to make the binary :(. Now there are two binaries in the directory ftp://209.133.33.182/pub/valor/bin one is for Alpha ev5-OSF and the other is for pentium GNU/Linux glib2.0 You can play with it. Regards Guillermo. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P4
On Fri, 1 Dec 2000, Brian J. Beesley wrote: > On 1 Dec 00, at 0:13, [EMAIL PROTECTED] wrote: > > [... snip ...] > > How is any of this relevant to Mersenne testing? Well, fast 64-bit integer > > ops should make a well-designed all-integer convolution algorithm > > competitive with a floating-point-FFT-based one. However, neither of these > > two is truly satisfying since each basically uses just half the > > functionality (integer or floating-point) of the processor. > > Half the execution units ... but maybe there may already be a > bottleneck e.g. in the memory bus throughput, or in the instruction > decoder. This is definitely an issue with the Alpha 21264, which can execute 6 instructions per clock (four integer, 2 floating) but can only decode 4 instructions per clock. > If we were free to design a processor optimized for mega-precision > arithmetic, we'd have registers _much_ longer than 64 bits. We would > probably also have multi-operand instructions, allowing e.g. elements > of a radix-N FFT to be computed in a single instruction. At any rate > we _definitely_ want to be able to evaultate a * b + c as fast as > possible - and it is possible to calculate the result in the time > taken to do just the multiplication. > But we'd still need to move the operands between CPU registers and > main memory. This is likely to continue to represent a bottleneck, > which could only be got around by using very wide data busses and/or > very fast (static) RAM - strategies which would result in expensive > hardware systems. Or a huge pipeline with banked memory. This would actually not be extremely difficult: built a vector NTT butterfly ASIC with its own DMA engines, and connect it to multibank DRAM arrays. What you'd get is a vector processor which could execute convolution primitives. Sometimes I wish I knew more about hardware... jasonp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P4
On 1 Dec 00, at 0:13, [EMAIL PROTECTED] wrote: [... snip ...] > How is any of this relevant to Mersenne testing? Well, fast 64-bit integer > ops should make a well-designed all-integer convolution algorithm > competitive with a floating-point-FFT-based one. However, neither of these > two is truly satisfying since each basically uses just half the > functionality (integer or floating-point) of the processor. Half the execution units ... but maybe there may already be a bottleneck e.g. in the memory bus throughput, or in the instruction decoder. If we were free to design a processor optimized for mega-precision arithmetic, we'd have registers _much_ longer than 64 bits. We would probably also have multi-operand instructions, allowing e.g. elements of a radix-N FFT to be computed in a single instruction. At any rate we _definitely_ want to be able to evaultate a * b + c as fast as possible - and it is possible to calculate the result in the time taken to do just the multiplication. But we'd still need to move the operands between CPU registers and main memory. This is likely to continue to represent a bottleneck, which could only be got around by using very wide data busses and/or very fast (static) RAM - strategies which would result in expensive hardware systems. Regards Brian Beesley _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Factoring
> The problem is for the government to factor the huge composite number > for each candidate afterwards. Can someone give me a rough > estimate of > how long it would take a good supercomputer to check an arbitrary > 100,000,000 digit number for several factors that are each a known 150 > digit arbitrary prime? Not long at all, and you don't need a supercomputer. It's perfectly parallelizable. Use a room full of PCs and give them disjoint ranges of primes to test. A major problem, which no-one has yet commented on, is that the protocol as stated doesn't allow a secret vote. Only if no-one other than the voter knows who received which number, and the voter knows only his/her own, can it be secret. Patching up this hole is relatively straightforward and is left as an exercise for the reader ;-) Paul _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factoring
Paul Leyland wrote: > > > >We could let prime95 decide the next election . > > >Give everybody a different prime number. Multiply the primes for > > candidate A together, likewise for B. > > > > And like in this election, unless we can completely factor > > the results, > > we wouldn't know who won, either. > > > > :) > > I note the smiley, but I also assume that we know the original primes as > well, as it's built into the double voting detection mechanism. If after > dividing through all allocated primes the residue is > 1, we can conclude > that at least one voter registered a protest by spoiling their ballot paper. > Note that we also know who did *not* vote, if their prime doesn't appear in > either product. > > A major problem with this protocol as I see it is that a third party can > steal your vote by stealing your prime and using it first. These problems could be solved by storing the primes on a single, secured machine and then sending them to voters, eg, on a floppy through certified mail. Correct me if I'm wrong, but by using primes with, say, 150 decimal digits generated from strong random numbers, we'd be quite safe. The problem is for the government to factor the huge composite number for each candidate afterwards. Can someone give me a rough estimate of how long it would take a good supercomputer to check an arbitrary 100,000,000 digit number for several factors that are each a known 150 digit arbitrary prime? Nathan _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Glucas v.2.0 released
Hi: After some delays, here is Glucas 2.0. Now I think it is stable enough to try complete Lucas-Lehmer test from PRIMENET (using manual forms, of course). You can download the package from E.W.MAYER server (thanks Ernst): ftp://209.133.33.182/pub/valor/Glucas-2.0.tar.gz You can read more about Glucas in ftp://209.133.33.182/pub/valor/README.Glucas.htm The performance is near Mlucas when it is well tuned. It can be a good chance to extent GIMPS and Lucas-Lehmer test to platforms with good C-compilers but no expensive f90 ones. The actual release is, at the moment, for the UNIX/Linux world and all its variants. For x86 users, of course, you should use mprime (Glucas is about 65% of performance with respect mprime), but Glucas can be used for Double-Check proposes. Some remarkable features of this release are: -It uses the Interchangeable Mersenne Residue File Format to save files. We can use the save files in most of the systems (and they are very compacted). Nevertheless, it has backward compatibility for Will Edgington rw() routines used in MacLucasUNIX. -There is no problem with accuracy. Glucas adjust the FFT runlength size at run time whether the roundoff error are too high. -It is coded using intensively C-macro facilities. It is relatively easy to write small assembler macros to speed it up (as made for x86's GNU/gcc compiler ). There are still no precompiled binaries. I think soon will be binaries for Alpha-Osf (ev56, ev6). Thus, you have to make the binary :(. We need some Unix's GURUs to make the binaries as fast as possible. You can read in the documentation how to test and timing Glucas. Any help, feedback or suggestion is welcome. Regards Guillermo. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Factoring
> >We could let prime95 decide the next election . > >Give everybody a different prime number. Multiply the primes for > candidate A together, likewise for B. > > And like in this election, unless we can completely factor > the results, > we wouldn't know who won, either. > > :) I note the smiley, but I also assume that we know the original primes as well, as it's built into the double voting detection mechanism. If after dividing through all allocated primes the residue is > 1, we can conclude that at least one voter registered a protest by spoiling their ballot paper. Note that we also know who did *not* vote, if their prime doesn't appear in either product. A major problem with this protocol as I see it is that a third party can steal your vote by stealing your prime and using it first. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
