Mersenne Digest Friday, September 24 1999 Volume 01 : Number 631
----------------------------------------------------------------------
Date: Wed, 22 Sep 1999 22:02:22 -0700
From: Kevin Sexton <[EMAIL PROTECTED]>
Subject: Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
"Brian J. Beesley" wrote:
> On 20 Sep 99, at 1:06, Rick Pali wrote:
>
> > The only question that comes to mind is if you had to plough through
> > factoring before you got to the LL test...but then I realise that you still
> > wouldn't be done if that were true.
>
> You don't have to pre-factor, if you choose "Test" or "Time" from the
> "Advanced" menu.
> >
> > I signed up for an exponent in the 33mil range and the factoring alone took
> > 13 days on a P3-500.
>
> Ah, so we're maybe not doing enough trial factoring. I guess your
> completion time is about a year; trial factoring should take between
> 5% and 10% of the time for a LL test, & 13 days is only about 3.5%. I
> think we should probably go one bit deeper, this would double the
> trial factoring time - but would save the whole year, if you managed
> to find a factor.
>
> > I'd originally does it for testing purposes, but after
> > that I've just got to let it continue. :-)
>
> Well, why not?
> >
> > In a year's time, I'd love to see some numbers on how many signed up for tem
> > million digit numbers and later quit for smaller exponents...
>
> I think you need to be a true enthusiast to take on a single test
> taking ~ 1 year. Lots (attracted by ca$h) won't realise what it
> means, for a week or two, & may then drop out 8-( To avoid this
> happening to too many people, I think we should be a bit more upfront
> that testing a 10 million digit number is going to take about a year,
> even on a state-of-the-art system.
>
> I have several fastish systems - a couple of them are running QA
> stuff at the moment - I may voluntarily take on a 10 million digit
> number on _one_ of them, but I certainly wouldn't choose to run tests
> of that length on _all_ of them!
>
> Regards
> Brian Beesley
> _________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
> Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Notice that in v19 if you set it to get 10 Million range numbers you get a warning
about it taking a year on a 500 Mhz P-2, and odds of 1 in 250,000.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 01:37:11 -0500
From: Ken Kriesel <[EMAIL PROTECTED]>
Subject: Mersenne: QA testers call
I am looking for about 20-50 additional ambitious & very patient QA testers
with extremely fast hardware, and some significant free storage space, to
participate in runs on selected exponents in the larger fft runlengths.
The selected exponents will frequently be fully trial factored, or nearly so.
Though many may be prime95 or mprime users, this is not a requirement, and
participation of users on nonIntel cpus is encouraged.
Participants in this phase of the QA should be willing to coordinate with
a partner, running LLtests and double-checks of the same exponent in parallel,
and cc George Woltman and myself, interim residues at suitable intervals.
Interim files (which can each be sizable) should be preserved until interim
residues of a later interim check are known to match. (Ideally all interim
files would be kept, at intervals of 1-2 million iterations, until an
exponent is completed & double checks ok.)
Participants should agree to sign on for at least 6 months, preferably much
longer, and to transmit the last valid intermediate file or interim file to
an ftp server if quitting, or when necessary for debugging.
(Note, the upper end, 79,300,000, takes an estimated 6.5 years on a
PentiumII-400, nonstop.)
Participants should agree to install version upgrades that may be required
from time to time, waiting a day or more to ensure it's a stable version,
and migrate the tests in progress to their fastest
available hardware as hardware upgrades are made.
(It may be possible to get partial cpu-time credit for partially LLtesting
an exponent that is then completed by someone else but this is not guaranteed.
This could be an extra administrative headache for George Woltman and myself.)
In exchange for all this time and trouble, testers will have a reduced
chance of finding a prime and a delay in receiving cpu credit (due to the
long runtimes), but get a shot at completing primality tests of exponents
unlikely to be surpassed for some time.
The purposes of this endeavor are:
1) Add to the list of known, checked residues, some entries in currently
very sparse or completely empty runlengths (ahead of checkout & result
return by typical GIMPS & Primenet users) for qualification of v19 prime95
& its variants, future versions, & other software.
2) Verify the long term operation accuracy of prime95 v19 and its relatives
(and later versions) in the new longer runlengths.
3) Gain experience with the tandem-running approach.
4) Have fun.
Volunteers, please respond by email to me with the following information:
Your full name
your email address
your preferred runlength(s)
how many exponents you'd like to take on in each runlength
Description of cpus available for QA testing, as in the hypothetical
example below, to judge suitability of cpus for various exponents:
Name CPU OS RAM available (hr/day)/(day/wk)
xyz PII-500 WinNT (build 1381 SP5) 128MB 24/7
a Alpha21264-600 TruUnix Vxxx 512MB 15/5 +24/2
5; various Celeron500 Win95 128MB 24/7
omega 4xPIII-600 WinNT 4sp5+hotfixes 256MB 24/7
(CPU descriptions will not be shared among participants or with the mail
list.)
Ken
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 11:42:20 +0200
From: Philippe Trottier <[EMAIL PROTECTED]>
Subject: Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
HI!
Anyone tought of send ing these P and Q once a month to the server.. in the
case where someone would abandon a quest, it could be continued by someone
else ...
>Notice that in v19 if you set it to get 10 Million range numbers you get a
warning
>about it taking a year on a 500 Mhz P-2, and odds of 1 in 250,000.
If the price would be won the split would be according to CPU cyle or CPU
time !?!?!?!
Philippe
BTW for the nice Screen Saver interface I would suggest some fun GFX
(something easy to draw) from the residue of each Iteration with a Bar
decreasing with the work to do on the exponent
I don't know how the software of primenet work but When I wanted a really
fast execution I was doing like so (The last time I coded it was in 1991)
A=0
"do it"
do job on A
do job on A
do job on A
do job on A
... (as many times it's logical depend on size order)
do job on A
if A<value go "do it"
if A>value do it backward till it's OK ( if you pass straight ahead oops)
JUMP "done"
Other of my trick was to do the same
unchecked bunch of ADD then till a register create a CPU fault, trap the
fault and see were is the registers =) That was removeing all the checking
of condition till I had a fault ... saving many little cycles
These are just theory
Philippe
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 13:53:33 +0200
From: Alexander Kruppa <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Front-end design
Robert van der Peijl wrote:
>
> He further writes:
> There are some Linux folks that like the present program because it
> doesn't use X-windows.
I certainly do! A program like mprime that is supposed to run in
background at all times should not depend on a X server running. Maybe
the setup could be handled similar to the NT service version, with the
actual client running without screen I/O in background, and a GUI
program to handle .ini file setting, Status reports, etc. Since the GUI
would not involve any speed-critical code, perhaps it could even be
written in TCL/TK or somesuch.
Also, while a bit unrelated, I would rather like a command line driven
option of mprime, perhaps like the perl one-liner option -e, i.e.
mprime -d -e "ECM=727,44000000,0,1,0,0,0,64"
to do a single curve on M727 and ignoring worktodo.ini. I guess there is
a feature freeze on v19.0, but perhaps this can go in a future version
of mprime?
And sometimes it would be handy to have an option to unreserve specific
exponents from within Prime95, like you can do on the Manual Testing web
pages of Primenet.
Ciao,
Alex.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 16:18:19 +0100
From: Robin Stevens <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Front-end design
On Thu, Sep 23, 1999 at 01:53:33PM +0200, Alexander Kruppa wrote:
> Robert van der Peijl wrote:
> > He further writes:
> > There are some Linux folks that like the present program because it
> > doesn't use X-windows.
> I certainly do! A program like mprime that is supposed to run in
> background at all times should not depend on a X server running.
Quite. For a start, some of the servers on which I have mprime running
don't have an X server. I'm not always logged into them, and X on my
desktop machine has been known to be less than fully stable (curse netscape
for taking down first X and then the entire machine the other day).
Meanwhile mprime can remain running for months without requiring a restart.
> Maybe the setup could be handled similar to the NT service version, with
> the actual client running without screen I/O in background, and a GUI
> program to handle .ini file setting, Status reports, etc.
Personally I don't see a need, but I can see that some people might (I saw
some 95 boxes the other day running the SETI screensaver, and it does look
quite slick). The mprime console program is fine, except that there are
now too many options for them to be displayed on a standard 80x24 window
or console - perhaps things could be rearranged slightly?
Incidentally, can anyone explain why under v19.0.2 I'm getting "ERROR 2250:
Server unavailable" messages? Since 18.1.2 as running on another machine
has no problems, it's evidently not a case of the server being down. The
FAQ mentions a problem on v18 for those using RPC, but I was under the
impression I've always been using http...
- --
- -------------------- Robin Stevens <[EMAIL PROTECTED]> --------------------
Merton College, Oxford OX1 4JD, UK http://www-astro.physics.ox.ac.uk/~rejs/
(+44) (0)1865: 726796 (home) 273337 (work) 273390 (fax) Pager: 0839 629682
When puns are outlawed only outlaws will have puns.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 11:27:23 -0400
From: George Woltman <[EMAIL PROTECTED]>
Subject: Mersenne: Oops again - Version 19 - beta #4
Hi all,
Only Linux users are affected. Apparently I suffered floppy confusion or
other operator error in rebuilding beta #4 for linux. The corrected
beta #4 for linux is now available.
The linux beta dynamicly linked with glibc 2.1 is at:
ftp://entropia.com/gimps/mprb.tgz
The linux beta staticly linked is at:
ftp://entropia.com/gimps/sprb.tgz
Sorry for the trouble,
George
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 17:27:00 +0100 (BST)
From: Chris Jefferson <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Front-end design
Sorry, I've deleted the mail. QWhere can I get the most recent Prime95
source code from, and what should I compile it with? I'd like to at least
try to make a front-end, and I'm sure at least the base of a screen saver
would take all of 30 minutes. I know that we'd perfer people to use
prime95 all the time, but a screen saver would be useful for people who
refuse to...
- ------------------------------------
Chris Jefferson, Girton College, Cambridge, [EMAIL PROTECTED]
- ------------------------------------
Someone may have beaten me to Fermat's Last Theorem, but I've done
Riemann's general equation. However it won't fit in my signature file...
- ------------------------------------
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 15:03:05 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Mlucas 2.6/2.7: corrections
Dear All: some corrections to my two postings of yesterday (West Coast U.S.
yesterday, at least):
The error summary for Mlucas 2.6c should read as follows:
1) Any first exponent at a particular FFT length should be fine;
2) Any subsequent exponent at the same length (whether there are exponents
using a different runlength between them or not) will be bad.
Some of the Alpha 21064 timings in the Mlucas 2.7 timings table were wrong
(they were for 2.6, not 2.7). The corrected table follows - the corrected
timings
are indicated with a +. I also replaced the tabs with spaces, so hopefully the
table will transmit better this time. (If it's misaligned on your end, try
switching
your browser or edit window to a true type font):
Platform/per-iteration time (sec)
200MHz 21064 400MHz 21164 195MHz R10K 250MHz R10K
cache sizes 8KB L1 32kB L1 32kB L1
unknown 96KB mixed
512KB L2 4MB L2 1MB L2
FFT length ---------- ---------- ---------- -------------
64K .095 .035 .041 .035
80K .12 .045 .054 .047
96K .16 .057 .069 .062
112K .19 .069 .082 .074
128K .21 .078 .100 .090
160K .27 .098 .118 .115
192K .32 .115 .143 .144
224K .39 .140 .170 .170
256K .48 .177 .221 .210
320K .65 .241 .261 .248
384K .81+ .316 .345 .317
448K .98+ .399 .388 .354
512K 1.17+ .545 .525 .451
640K 1.50+ .620 .649 .543
768K 1.82+ .756 .814 .659
896K 2.16+ .890 .932 .771
1024K 2.42+ 1.20* 1.16 .937
1280K 3.20 1.32 1.40 1.13
1536K 4.15 1.86 1.90* 1.54*
1792K 4.99 2.13 2.04 1.68
2048K 5.45 2.73 2.57 2.22
2560K 6.93 3.16 3.25 2.61
3072K 8.33 4.02 3.92 3.16
3584K 9.96 4.53 4.58 3.69
4096K 11.42 5.62 6.14 7.26*
Also, in my comments regarding the anomalous timings (*) in the table
yesterday, I had no explanation for the slowish 21164 time at 1024K. It
may in fact be that at 1024K FFT length, the small FFT sincos and DWT
weights tables (which contain sqrt(n) 64-bit floats each) are each 8KB and
thus can't reside completely in the 21164's 8KB L1 cache along with anything
else. The MIPS R10000 has a 32KB L1 cache, so doesn't suffer the same
problem. Thus, the only remaining unexplained anomaly is the truly bizarre
behavior on the 250MHz R10000 at 4096K.
- -Ernst
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 16:46:30 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Re: FFTW for GIMPS?
Guillermo Ballester Valor writes:
<< Do you Know the GNU-FFTW package ?(The Fastest Fourier Transform in the
West). Last week I thought it would be interesting to see if it is as
fast as they say. It is really a fast C-written FFT code. >>
Hi, Guillermo (please, let's use first names - I'm an informal guy) -
While not having used it myself, certainly I've heard of FFTW. Note that
a better person to comment on your questions might be Jason Papadopoulos
([EMAIL PROTECTED]) - he adapted FFTW for his very fast SPARC Fermat
number code.
My comment is this: If you want to create a fast FFT-based program in a
short time, FFTW is certainly a good way to do it. On the other hand, if
you're really striving for extreme performance (i.e. trying to write a
code that possibly many people will use intensively), it is best to have
a code whose details you understand well. In my case, the latter criterion
(and the fact that I wanted to learn as much as I could about FFTs) led me
to write my own code. I started with the Numerical Recipes FFT (slow and
not very accurate, but easy to play with) about 3 years ago and have been
working on it ever since - my current code looks nothing like the NR FFT,
but you have to start somewhere.
Looking at the FFTW timings page, for a length-262144 real-vector transform
they list (http://www.fftw.org/benchfft/results/alpha467.html)
a performance of around 105 "MFlops" on a 467 MHz Alpha 21164. Using
their definition of MFlops for real FFTs, this translates to a per-FFT time of
0.5*[5*262144*log2(262144) Flop]/[115 MFlop/sec] = 0.112 sec.
My LL code does 2 FFT's plus other operations per Mersenne-mod squaring,
so we estimate about 80% of the per-iteration time equals one FFT. At 256K
vector length it needs .177 sec per iteration on a 400 MHz 21164, which
leads to an estimate of .40*.177*400/467 = 0.061 sec on a 467MHz 21164
which is significantly faster than FFTW.
At real-vector length 362880 (the closest I could find to 384K), FFTW needs
0.5*[5*362880*log2(362880) Flop]/[125 MFlop/sec] = .134 sec per FFT,
whereas Mlucas 2.7 (multiplying the 384K = 393216 timing by 362880/393216
to get a comparison with the FFTW timing for the latter length) needs
.40*.316*(400/467)*(362880/393216)) = .100 sec per FFT on a 467 MHz 21164.
On a 195 MHz MIPS R10000 CPU (SGI Origin 2000 workstation) FFTW needs
0.5*[5*262144*log2(262144) Flop]/[62 MFlop/sec] = .190 sec at n=262144
0.5*[5*362880*log2(362880) Flop]/[67 MFlop/sec] = .250 sec at n=362880
whereas Mlucas 2.7 needs (again extrapolating the 384K timing backward to
362880) .088 and .127 seconds, respectively, per FFT on the same hardware.
The fact that it took me so much work to achieve these speeds is a
testament to the speed of FFTW - the sample timings I sent to Steven Johnson
(one of the authors of FFTW) last year were still generally slower than
FFTW. However, "rolling one's own" (as it were) allows one to do lots of
algorithm-specific optimizations not available to the FFTW folks. Since
FFT-based large-integer arithmetic can do a pointwise (dyadic) squaring
on the outputs of the forward FFT without them being ordered in any special
way, one can do a forward decimation-in-frequency FFT, followed by a
pointwise squaring of the (bit-reversal-reordered) data, followed by
decimation-in-time inverse FFT, thus avoiding the need for explicit
bit-reversal-reorderings of data (or matrix transposes, in the context
of the 4-step FFT used by FFTW), for example. One can also combine the
last pass of the forward FFT, the dyadic squaring and the first pass
of the inverse FFT into a single pass through the data. Similarly, one
can fuse the final pass of the inverse FFT, the rounding-and-carry-
propagation step, and the first pass of the forward FFT, which both
minimizes data movement (memory accesses) and allows one to propagate
carries for several sub-blocks of the full array in parallel fashion.
I'm sending a copy of this to both the Mersenne list and to Steven
Johnson, the latter so he can correct any gross errors I might have
made in my timings calculations for FFTW.)
Cheers,
Ernst
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 16:56:09 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: whoops
Please note that I mistyped Guillermo Ballester Valor's e-mail address in
sending
my last posting - it should be [EMAIL PROTECTED]
- -Ernst
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 17:45:39 -0400
From: George Woltman <[EMAIL PROTECTED]>
Subject: Mersenne: Linux error 2250 (was Front-end design)
Hi Robin.
At 04:18 PM 9/23/99 +0100, Robin Stevens wrote:
>some of the servers on which I have mprime running don't have an X server.
The original poster was talking about a GUI executable available in
addition to - not a replacement for - mprime.
>Incidentally, can anyone explain why under v19.0.2 I'm getting "ERROR 2250:
>Server unavailable" messages?
Someone told me that glibc-2.1 (as compared to v18's libc5) uses different
files or network setup or something. I am a Linux know-nothing, so perhaps
a list member can enlighten all of us.
Regards,
George
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 15:15:08 -0700
From: Will Edgington <[EMAIL PROTECTED]>
Subject: Re: Mersenne: M(M(127)) and other M(M(p))
Chris Nash writes:
I really hope that neither Will Edgington (with M(M(6972593))) nor Chip
Kerchner (with M(M(1398269))) dedicated any computer time whatsoever to
search for factors 2*k*M(p)+1 up to k=4.
I didn't, except perhaps to have mmtrial verify that the smaller k's
were sieved out.
As Will's page
http://www.garlic.com/~wedgingt/MMPstats.txt
points out, since M(p)=1 mod 3, k cannot be 1 mod 3. Also, since M(p)=-1 mod
8 for odd p>=3, k must be 0 or 1 mod 4 (otherwise 2 is not a quadratic
residue of this supposed factor, the 8x+-1 condition).
Thanks; I'll add this to the next MMPstatus file and to mmtrial.c.
Should have thought of it myself, but quadratic residues are still new
to me.
Will
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 18:52:40 -0400
From: Jud McCranie <[EMAIL PROTECTED]>
Subject: Mersenne: Conflict with Windows Schedule agent?
Has anyone noticed a conflict between Prime95 and Windows 98 SE scheduling
agent? With Sch agent on, just about every application will sometimes lock
up when I click on something. With Sch agent off, it is OK. The only
thing (other than the regular system stuff) that I have running is
Prime95. Any ideas?
+---------------------------------------------------------+
| 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
------------------------------
Date: Thu, 23 Sep 1999 16:02:13 -0700
From: Will Edgington <[EMAIL PROTECTED]>
Subject: Mersenne: Updated info on M(M(p))
The list of known factors of iterated Mersenne numbers recently
forwarded to these lists include all factors known to me, but the
search limits have been significantly improved, some well before
Nov. 1996 I believe.
The MMPstats.txt file that I maintain is about to be updated to the
following. If you do not have web access, feel free to email me; I
can arrange to have it emailed to you automatically when it changes as
part of the script that updates my web pages.
Note the implication that I try to keep track of who is working on
which exponents; this is simply to avoid duplication of effort.
Will
http://www.garlic.com/~wedgingt/MMPstats.txt
mersfmt.txt
mersenne.html
Status of M(M(p)) where M(p) is a Mersenne prime
$Id: MMP.status,v 1.49 1999/09/23 23:00:18 wedgingt Exp $
A factor will always be of the form 2*k*m + 1 where m = M(p) = 2^p - 1
is a Mersenne prime.
'U: k=61' is short-hand that trial factors <= 2*k*m + 1 have been checked.
The format is otherwise based on my usual Mersenne format, described
in <A HREF="http://www.garlic.com/~wedgingt/mersfmt.txt"> mersfmt.txt </A>.
Note that, since m == 1 (mod 3), factors of M(m) cannot have k == 1 (mod 3)
since 2*k*m + 1 == 0 (mod 3) in that case.
Chris Nash pointed out on the Mersenne list (1999 Sep 22) that, for
odd Mersenne exponents, k must be 0 or 1 mod 4, since,
otherwise, 2 is not a quadratic residue of the supposed
factor.
Credit for first find of each factor (C: line) is given to the best of
my knowledge. The one with my name is from my pre-GIMPS (see
www.mersenne.org) data and probably pre-dates W. Keller's
(also unpublished) 1994 discovery.
Note that I have no P-1 factoring info for M(p) > M(17) and no P-1
save files.
M( M( 2 ) )P
M( M( 3 ) )P
M( M( 5 ) )P
M( M( 7 ) )P
M( M( 13 ) )C: 338193759479 # k = 20644229, Wilfrid Keller (1976)
M( M( 13 ) )H: 2^55 # Charles F. Kerchner III, Prime95, stopped
M( M( 13 ) )H: k=2199291723780 # "
M( M( 13 ) )o: 3e9 # Warut Roonguthai, Factor95, stopped (no P-1 save
file)
M( M( 17 ) )C: 231733529 # k = 884, Raphael Robinson (1957)
M( M( 17 ) )C: 64296354767 # k = 245273, Wilfrid Keller (1983?)
M( M( 17 ) )H: 2^60 # Charles F. Kerchner III, Prime95, stopped
M( M( 17 ) )H: k=17592320263168 # "
M( M( 17 ) )o: 3961649 # (unknown, no P-1 save file)
M( M( 19 ) )C: 62914441 # k = 60, Raphael Robinson (1957)
M( M( 19 ) )C: 5746991873407 # k = 5480769, Will Edgington (Wilfrid Keller 1994)
M( M( 19 ) )H: 2^60 # Warut Roonguthai, Prime95, stopped
M( M( 19 ) )H: k=4398054899728 # "
M( M( 31 ) )C: 295257526626031 # k = 68745, Warut Roonguthai (Guy Haworth 1983)
M( M( 31 ) )C: 87054709261955177 # k = 20269004, Tony Forbes (Wilfrid Keller
1994)
M( M( 31 ) )H: 1984697089407967495
M( M( 31 ) )H: k=462098301
M( M( 61 ) )U: k=9363198284 # Landon Curt Noll, own program, stopped
# Sturle Sunde, continuing 1999 Sep 22
M( M( 89 ) )U: k=13516351613 # Landon Curt Noll, own program, stopped
M( M( 107 ) )U: k=2016797660 # Landon Curt Noll, own program, stopped
M( M( 127 ) )U: k=1250000000000 # Landon Curt Noll, own program, continuing
M( M( 521 ) )U: k=20000000 # Rob Hooft, mmtrial, stopped
M( M( 607 ) )U: k=6170000 # Samuli Larvala, own program, stopped
M( M( 1279 ) )U: k=17758437 # Conrad Curry, mmfac (see below), stopped
M( M( 2203 ) )U: k=11356378 # Conrad Curry, mmfac, stopped
M( M( 2281 ) )U: k=3026696 # Rob Hooft, mmtrial, stopped
M( M( 3217 ) )U: k=304345 # Eric Prestemon, mmtrial, stopped
M( M( 4253 ) )U: k=580000 # Conrad Curry, mmfac, stopped
M( M( 4423 ) )U: k=880000 # Conrad Curry, mmfac, stopped
M( M( 9689 ) )U: k=69034 # Conrad Curry, mmfac, stopped
M( M( 9941 ) )U: k=14000 # Conrad Curry, mmfac, stopped
M( M( 11213 ) )U: k=2573 # Eric Prestemon, mmtrial, stopped
M( M( 19937 ) )U: k=1501 # Conrad Curry, mmfac, stopped
M( M( 21701 ) )U: k=7123 # Conrad Curry, mmfac, stopped
M( M( 23209 ) )U: k=2731 # Conrad Curry, mmfac, stopped
M( M( 44497 ) )U: k=30169 # Chris Nash, by sieving possible factors,
1999 Sep 21
M( M( 86243 ) )U: k=271 # Conrad Curry, mmfac, stopped
M( M( 110503 ) )U: k=7 # Will Edgington, mmtrial, stopped
M( M( 132049 ) )U: k=40 # Will Edgington, mmtrial, stopped
M( M( 216091 ) )U: k=19 # Charles F. Kerchner III, own program
M( M( 756839 ) )U: k=23 # Charles F. Kerchner III, own program
M( M( 859433 ) )U: k=32 # Charles F. Kerchner III, own program
M( M( 1257787 ) )U: k=7 # Charles F. Kerchner III, own program
M( M( 1398269 ) )U: k=4 # Charles F. Kerchner III, own program
M( M( 2976221 ) )U: k=55 # Eric Prestemon, mmtrial, stopped
M( M( 3021377 ) )U: k=43 # Charles F. Kerchner III, own program
M( M( 6972593 ) )U: k=4 # Will Edgington, mmtrial, stopped
Rob Hooft has sent me a copy of his program, mmtrial, which uses
freeLIP; it is in the mers package, which is available <a
href="http://www.garlic.com/~wedgingt/mers.tar.gz"> here </a> on <a
href="http://www.garlic.com/~wedgingt/"> my personal web pages </a>.
Conrad Curry's mmfac program is available on <a
href="ftp://ftp.netdoor.com/users/acurry/"> his ftp site </a> as <a
href="ftp://ftp.netdoor.com/users/acurry/mmfac.zip"> mmfac.zip </a>
His ecm3 for DOS, a port of the mers package's ecm3 v4.1, is also
there as <a href="ftp://ftp.netdoor.com/users/acurry/ecm3.zip">
ecm3.zip </a>.
Please send updates, corrections, questions, and new information to
<a href="mailto:[EMAIL PROTECTED]"> [EMAIL PROTECTED] (me) </a>.
Thanks,
Will Edgington
Last updated: $Id: MMP.status,v 1.49 1999/09/23 23:00:18 wedgingt Exp $
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 21:02:34 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Mlucas 2.7: whoops #2
Oops - I just noticed that I mistyped the IP# for my ftp server in my postings
yesterday - cut and paste, the fastest way to propagate errors throughout
one's
document. The correct ftp is
ftp://209.133.33.182/pub/mayer/README
Using my own terminology, a code which is at (or said to be at) a non-existent
ftp site has a relative performance index of 0...
Better luck this time,
- -Ernst
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 24 Sep 1999 02:24:32 +0100
From: "Ian L McLoughlin" <[EMAIL PROTECTED]>
Subject: Mersenne: version 19 and confusion
Hi,
I have been reading postings with interest...
I have the idea that most people posting to the list are software
programmers.
I am a humble chemist more into 2,4-Dihydroxybenzene or
antivirals..(Acyclovir??)
I tried to install the version 19.0 expecting it on Win 98 to supplant my
existing files...but no joy..
I am already testing a LL exponent, and all it did was create another
version and give me other exponents to test..
I must admit the interface (GUI) on this is not as good as the Seti
programme...which I indulged in for one month...Correct me , but I thought I
would rather use my spare cycles for something a bit more tangible than
looking at a short bandwidth with fft for something that is quite
frankly..well...very UNTENABLE?
As a non-programmer totally illeterate(!) user of Prime 18 with a Cyrix
333MII.. 8-( I feellike left out of the equation, if you forgive the pun...
Really I want to know about the difference between floating point
computation and integer based calculations.
I really like this number theory exercise, primarily having read the work of
Andrew Wiles on proving
Taniyama-Shimura conjecture (Modular forms) -Eliptic equations...coupled
with Galois Representations and Hecke algebras...
I must admit, I like Hilbert best of all...
Perhaps somebody can write a programme for pur integer based
calculations.,???
Sorry, I am rambling....
All the best to Primenet and subscribers.
feedback much appreciated...
A poor chemist...(Could hardly understand Heisenberg's uncertainty
principle...8-)
Regards from U.K.
Ian McLoughlin, Chematek U.K.
Tel/Fax : +44(0)1904 679906
Mobile : +44(0)7801 823421
Website: www.chematekuk.co.uk
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 23 Sep 1999 23:54:25 -0500
From: Ken Kriesel <[EMAIL PROTECTED]>
Subject: RE: Mersenne: QA testers call
At 09:36 AM 1999/09/23 -0700, Paul Leyland wrote:
>Hi Ken, that's a challenging project you're proposing.
>
>I'm very nearly tempted by this one, but the 6-year run time is a bit
>daunting. In the past I've devoted months to a single factorization but
>I've no real idea what I'll be doing in six years time or what hardware I'll
>have access to.
To clarify, it is not a requirement that individual volunteers stay with
the project the full run-time of the exponents they're working on.
If/when quitting before completion, pass the intermediate file & interim
files on to those carrying on from there.
I've been hunting mersennes since 1985, so the odds are I'll stick with
it a while, barring major unexpected events.
>It's also not clear what the payback will be.
The payback is that known-results exponents in completely new territory
will be available against which any mersenne codes developed can be tested.
The odds are low, but it's a nonzero probability that a prime could be found
in the process.
>However, I've not yet completely ruled out volunteering, but need a bit more
>incentive and a bit more information. For instance, how big are the files
>I'd need to keep around, and how many for how long?
(Note: file sizes appear to be the runlength size (ie: 112K = 114,688) x 4
plus 18 bytes for v18 and 22 bytes for v19)
For v19:
Exponent FFT,K Size of 1 save
Limit file, bytes
1990000 96 393238
2323000 112 458774
2655500 128 524310
3290000 160 655382
3935000 192 786454
4598000 224 917526
5250000 256 1048598
6515000 320 1310742
7730000 384 1572886
9020000 448 1835030
10320000 512 2097174
12830000 640 2621462
15270000 768 3145750
17850000 896 3670038
20400000 1024 4194326
25330000 1280 5242902
30100000 1536 6291478
35100000 1792 7340054
40250000 2048 8388630
49900000 2560 10485782
59400000 3072 12582934
69000000 3584 14680086
79300000 4096 16777238
>Space, per se, is not a
>real problem (as long as it's not more than, say, 10Gb) but having to keep
>them safe for years means ensuring they are backed up and so forth. When we
>did RSA-155 my contribution to the relations (about 1/6 of the total) took
>800Mb when compressed but needed to be preserved only for a couple of months
>and the copies at CWI acted as my backup, and vice versa.
To work a worst case example, 79,300,000 run at InterimFiles=1000000
would leave 80 copies (79 interims & the final) x 16MB or 1.3GB.
It isn't necessary that any one person among the testing volunteers store
more than a few exponents interim file sets, unless they are running
many exponents in parallel.
>Another question: how hard are you planning to try to factor Mersenne
>numbers? With an effort you are planning, it would make sense to me to
>spend a cpu year or so trying to factor.
Right; we are factoring to the default v19 depth, enough exponents
to get at least 3 LL-testable candidates in each runlength.
>This *can* be trivially
>parallelized and I would be happy to contribute to this phase. With the
>resources I have, I can spend a PII-400 year factoring every week or two. I
>don't mind slipping in that much between my regular jobs.
Paul, I'll be sending you some candidate exponents to continue factoring to
the full depth.
Ken
Ken Kriesel, PE <[EMAIL PROTECTED]>
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 24 Sep 1999 09:21:12 +0000
From: "Steinar H . Gunderson" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: version 19 and confusion
On Fri, Sep 24, 1999 at 02:24:32AM +0100, Ian L McLoughlin wrote:
>Really I want to know about the difference between floating point
>computation and integer based calculations.
To put it short: FP is _much_ faster on all CPUs. Even on the Cyrixes, which
have very slow FP.
>Perhaps somebody can write a programme for pur integer based
>calculations.,???
Sorry, it would be even slower than using FP-only. If you'd like work well
suited to your Cyrix, you can always do factoring -- there is an integer-
only version of the factoring algorithm, which is automatically used if you
say you have a Cyrix or a 486.
/* Steinar */
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 24 Sep 1999 18:38:04 +0300
From: Jukka Santala <[EMAIL PROTECTED]>
Subject: Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
Philippe Trottier wrote:
> I don't know how the software of primenet work but When I wanted a really
> fast execution I was doing like so (The last time I coded it was in 1991)
*snap*
Sounds like loop unrolling is what you're talking about. Most modern compilers (try
to) do this already automatically. However, I've experimented on different variations
of this with the Linux source to, I think, v16 or so, where it seemed possible to
attain small benefits from various variations of look-unrolling. The biggest problem
here is that the number of iterations isn't divisible by any fixed amount. Because of
that the last few iterations need to be done "manually" outside the unrolled block.
The main advantage of such unrolling comes from not needing to check for the number
of timed events present in Prime95/mprime between each iteration - due to cache
considerations actually copying the whole FFT code out as many times as needed
instead of just using calls to it is probably even worse.
I've posted about this suggestion before on this list, so I hope the possible
optimizations have been taken into consideration in v19 already, altough with the
exponent increasing the FFT code is starting to take more and more time and the
optimization of all the rest of the code become less important. I seem to also have
forgotten the rest of the optimizations I've toyed with ;>
-Donwulff
_________________________________________________________________
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 #631
******************************
