Mersenne Digest       Thursday, October 14 1999       Volume 01 : Number 643




----------------------------------------------------------------------

Date: Wed, 13 Oct 1999 21:18:16 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Mlucas 2.7: Alpha/Linux, SPARC binaries available

Dear All:

Thanks to Brian Beesley <[EMAIL PROTECTED]> and Francois Jaccard, I have
Alpha/Linux binaries of Mlucas 2.7y available: see ftp://209.133.33.182/pub/
mayer/README for details. Brian reports that the binary should run under
both Linux V5 and V6. He hasn't yet sent me timings for non-power-of-2
runlengths, but I expect these to be similar trends as the timings I recently
reported for Alpha/Unix, meaning a fairly smooth timing progression between
any given powers of 2. Here are some power-of-two length timings for Mlucas
and MacLucasUNIX on Brian's Alpha PC164 (basically an Alpha 21264A, a.k.a.
ev56, with a PC-style configuration):

***ALPHA/LINUX TIMINGS***

           Program, platform, cache sizes / per-iteration time in seconds

        Prime95.19 Mlucas2.7y MacLucasUNIX 6.25
        Intel      Alpha      Alpha
        PII/400    PC164/533  PC164/533
        8KB L1     8KB L1     8KB L1
        512KB L2   96KB L2    96KB L2
                   2MB L3     2MB L3
length  ---------- ---------- ----------
 128K   .060       .057 (79%) .064 (56%)
 256K   .132       .147 (67%) .156 (59%)
 512K   .281       .314 (67%) .320 (61%)
1024K   .600       .657 (68%) not run
2048K   1.23       1.56 (59%) not run
4096K   2.60       3.19 (61%) not run

Thanks to Bill Rea <[EMAIL PROTECTED]> I also have a binary for
SPARC Solaris V7; Bill assures me that one for Solaris 2.6 is coming soon.
The above README file says where to get the binary and how to install
the f90 RTL files needed to run it.

***SPARC TIMINGS***

Notes: (1) I include timings for the ftp'able Mlucas 2.7y binary compiled
       without the -xprefetch flag and for an executable compiled with it.
       As you can see, the -xprefetch flag gives extremely unpredictable
       results, which are usually worse than default, but at some runlengths
       it gives a small speedup (indicated with a *) or even substantial
       speedup (**). If you have a lot of work to do at one of the * or **
       runlengths, compile yourself using -prefetch (make sure to compare
       100-iteration timings of the resulting binary with the default binary
       on your machine before starting a long run!) or contact Bill about
       getting a binary compile with -xprefetch.

       (2) Times for more-advanced Ultra systems (Ultra2i, E450) tend
       to be much better than the ones below, even at similar clock rates.
       For example, Alex Kruppa gets .183 sec/iterations for Mlucas at 256K
       on his 300 MHz Ultra 2i, and Bill Rea says he gets 0.43 and 0.29
       sec/iteration, respectively, for MacLucasUNIX at 512K on his
       300MHz/2MBL2 and 400MHz/4MBL2 E450.

Abbrevations:
               n/a = Length not available; must use next-higher power of 2.
               XXX = test not done due to insufficient host virtual memory.

        Prime95.19 Mlucas2.7y Mlucas2.7y MacLucasUNIX 6.25
                   noprefetch -xprefetch
        Intel      SPARC      SPARC      SPARC
        PII/400    Ultra5/360 Ultra5/360 Ultra5/360
        8KB L1     ? L1       ? L1       ? L1
        512KB L2   256KB L2   256KB L2   256KB L2
length  ---------- ---------- ---------- ----------
  96K   .045       .091 (55%) .158       n/a
 112K   .055       .130 (47%) .101**     n/a
 128K   .060       .123 (54%) .118*      .12 (56%)
 160K   .083       .184 (50%) .175*      n/a
 192K   .098       .192 (57%) .336       n/a
 224K   .119       .225 (59%) .228       n/a
 256K   .132       .260 (56%) .340       .25 (59%)
 320K   .173       .387 (50%) .369*      n/a
 384K   .211       .410 (57%) .680       n/a
 448K   .252       .475 (59%) .475       n/a
 512K   .281       .542 (58%) .710       .51 (61%)
 640K   .372       .797 (52%) .705**     n/a
 768K   .453       .865 (58%) 1.41       n/a
 896K   .536       1.00 (60%) .995*      n/a
1024K   .600       1.10 (61%) 1.44       1.08 (62%)
1280K   .776       1.42 (61%) 1.78       n/a
1536K   .934       1.83 (57%) 3.01       n/a
1792K   1.11       2.18 (57%) 2.01**     n/a
2048K   1.23       2.52 (54%) 2.46*      2.82 (48%)
2560K   1.64       3.55 (51%) 3.22**     n/a
3072K   1.99       3.80 (58%) 5.58       n/a
3584K   2.38       4.48 (59%) 4.49       n/a
4096K   2.60       5.12 (56%) 6.44       XXX

_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 00:58:49 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Islands of Truth

<<A while back on this list, we had a discussion on just this very thing, but
as it turns out, with some more notable examples, as you have seen, the
deviation, in percent, between so called pairs is pretty far and wide.  And
then you have to ask, well, what constitutes a pair anyway?  Within 10% of
each other?  20%?  Some pairs are ridiculously close when you look at 'em,
and some are pretty far apart but still close enough that some would call it
a pair still.  And there's no real correlation to the size of the exponents
either.  The deviation grows and shrinks all along the list of primes.>>

Humans are notoriously good at finding patterns in cluttered data. Problem 
is, they're also good at finding patterns in random data.  This ability is 
useful if you're strolling in a field and you see a flash of orange/black. 
"Uh oh. Tiger. Run!". It is not useful if you're looking at a shadowed image 
of a Mars mountain, or the distribution of Mersenne primes. There seem to be 
too many exceptions to the Island theory to make it viable, and islands 
aren't observed (to my knowledge) with any other groups of numbers. A while 
ago (some people still have this in their archives) I made a trio of 
conjectures.  <<(#1: That there's a prime around the 4M range that we're 
missing. #2: That the discovered M38, which all we knew about was that it was 
in the 6M range, was actually around 6.9M, which I was correct about, and #3: 
A conjecture about the decamegaprime.)>> The original statement of my 
conjecture is buried in a Mersenne Digest < #600, I think. So, to this I add 
a fourth conjecture:
#4: The Noll Island Theory is not valid. As more Mersenne primes are 
collected, statistical effects due to our small sample size will be lessened.

(I.E. 3 is prime, 5 is prime, 7 is prime, all odd numbers are prime.)

S. "Bonus points to you if you understand my subject and think its funny" 
L.</PRE></HTML>
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 08:27:40 +0100
From: Nick Craig-Wood <[EMAIL PROTECTED]>
Subject: Re: Mersenne: gzipped binary expansion of the largest prime

On Wed, Oct 13, 1999 at 11:10:29AM -0400, Darxus wrote:
> Can somebody give me the last few digits of the decimal expansion of
> (2^6972593)-1 so that I can verify my copy's intact ?

gp (also know as pari) is a good tool for this...

$ gp
                    GP/PARI CALCULATOR Version 2.0.17 (beta)
[snip]
(08:21) gp > ((2^6972593)-1)%10000000000
%1 = 2924193791

This took no time at all to calculate.  Whereas calculating the
complete decimal expansion took ages...
- -- 
Nick Craig-Wood
[EMAIL PROTECTED]
http://www.axis.demon.co.uk/
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 09:57:08 -0400 (EDT)
From: [EMAIL PROTECTED]
Subject: Re: Mersenne: Islands of Truth

Hi folks

> Humans are notoriously good at finding patterns in 
> cluttered data. Problem is, they're also good at
> finding patterns in random data.

The supposed clustering is in fact typical of 'random' data. Ask a human being to pick 
lottery numbers, the human perception of randomness is 'equally spaced' (so much so, 
the *average* human probably wouldn't pick two consecutive numbers but the probability 
of that happening is surprisingly high).

There's an older version of the Noll Island Conjecture that goes something like this. 
You can wait for a bus for hours and hours, then two come along at once. This was not 
called the Bus Island Conjecture - because it's common experience.

Humans are notoriously bad at applying their statistical intuition to the extreme 
circumstances, particularly when probabilities are low over a large number of trials. 
'Expectation' and all those sorts of measures relating to the central limit theorem 
just no longer hold up. The distribution of low-probability events such as very large 
Mersenne primes, buses arriving on a random schedule, clicks on a Geiger counter 
behave very differently from coin tosses.

> #4: The Noll Island Theory is not valid. As more
> Mersenne primes are collected, statistical effects
> due to our small sample size will be lessened.

Actually I think the "theory" is valid, at least in that we'd expect these sort of 
clusters - significance testing as you say is pretty much a lost cause with only 38 
data. The problem though is it makes no difference where the next one is, you can 
always shape the conjecture to fit the existing data.

Could anyone pick *one* new Mersenne prime that would either confirm or deny the 
island theory? I don't think you can. Just move the goalposts if you need to.

Chris Nash
Lexington KY
UNITED STATES



_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 08:52:52 -0600
From: "Alan Vidmar" <[EMAIL PROTECTED]>
Subject: Mersenne: Prime NT service v19 and CPU type/speed

I have successfully upgraded all of my clients to v19.  The 
majority of them are running the NT service.

Thanks George, et all.

I noticed that we now have more options with the CPU type and 
speed.  Will the selection cause a different algorithm to be used? 
More registers etc?

Also, when I have updated the CPU type from PPro to PII and PIII, a 
"prime.spl" file is created and the information is sent back to the 
server.  On the regular NT clients this results in the CPU counts 
to be updated on the server in the Individual Account Report. But 
none of the NT service clients updated this CPU information. They 
are still showing as being PPro.

I can tell that these clients did in fact complete the update as 
the prime server shows a current date in the "date updated" field, 
but again the CPU count has not updated.

Any ideas?

Alan


"A programmer is a person who turns coffee into software."
Alan R. Vidmar                   Assistant Director of IT
Office of Financial Aid            University of Colorado
[EMAIL PROTECTED]                    (303)492-3598
*** This message printed with 100% recycled electrons ***
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 18:37:08 +0300
From: Jukka Santala <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: splitting up 10m digit primes

"Steinar H. Gunderson" wrote:

> There are two problems with this approach. First, entropia.com will need
> some HD space to hold these files (they are big...). Second, they will
> also need bandwidth to receive all those big (and not very compressible)

Personally, I think the big problem with regards to this is not people
quitting so much as the possibility of major hard-drive failure etc. on the
testers. I doubt many of them keep good backups (And the client is supposed
to run undisturbed, anyway) and with a test taking anywhere from year to two
it's bound to become an increasily common experience for somebody's
hard-drive to give up the ghost, or an error/virus wipe the drive clean, and
the person running the test not only lose the work but probably take their
anger out on PrimeNet once they learn there's no way to recover the work.

The transfer bandwidth and storage space are another problem. An idea I've
been toying with is extending the concept of "distributed computing" to
include "distributed storage". It poses it's own problems, but none seemingly
unbeatable. In essence PrimeNet would ensure that at least two machines have
the intermediary file (at most month old) at any time. In practice this would
be a new choice in the PrimeNet communications section for "Accept backup
work". The main problem comes when trying to solve the bandwith question -
best would be for the clients to exchenge the backups direct, but this would
need some extra work, assuming the clients were simultaneously online etc.
Also one would have to ask what would be the incencitive for someone to act
as a backup server... or prevent them from "stealing the work" as it were, by
using high-speed computers to finish the test a month before the main person
does in hopes of getting the prize.

 -Donwulff

_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 18:15:52 +0100 (BST)
From: Chris Jefferson <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: splitting up 10m digit primes

> Also one would have to ask what would be the incencitive for someone to act
> as a backup server... or prevent them from "stealing the work" as it were, by
> using high-speed computers to finish the test a month before the main person
> does in hopes of getting the prize.

I think that the new licence could stop people from doing this, or could
quickly be altered to say so, as I assume that a new version would need to
be bought out to support it possibly... or at least make it easier...

In my personal opinion, the best way of doing this would be to set up 3
computers in a 'loop' all doing the same exponent. Then they could
communicate at regular intervals. Although it would mean working at the
slowest speed, it might be a good idea to, along with backing up, get the
to cmpare exponents at the same time. This would fix the problem of one of
them quitting, another could be 'bought in', and also would allow
double=checking as the check went along. However, I suspect the
programming would be quite difficult.....

Chris


> 
>  -Donwulff
> 
> _________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
> Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers
> 

_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 13:22:50 -0400
From: Jud McCranie <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Islands of Truth

At 09:57 AM 10/14/99 -0400, [EMAIL PROTECTED] wrote:


>The supposed clustering is in fact typical of 'random' data.


Didn't someone on this list test the data for randomness using a Poisson 
distribution a few months ago?


+---------------------------------------------------------+
|     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, 14 Oct 1999 13:55:52 -0400 (EDT)
From: [EMAIL PROTECTED]
Subject: Re: Mersenne: Islands of Truth

>> The supposed clustering is in fact typical
>> of 'random' data.
> Didn't someone on this list test the data for
> randomness using a Poisson distribution a few months
> ago?

I remember suggesting it but not being statistically bright enough (or motivated 
enough) to know how to do it... I know someone did test it, though. (Brian maybe?).

The results were the usual statistical double-talk... e.g. "There is not enough 
evidence to suggest that the (logarithmic) gaps do *not* follow a Poisson 
distribution". There's nothing in the existing data to indicate anything other than 
natural, uncorrelated, Geiger-counter type noise.

In particular, as yet the island theory has no statistical support. Our eyes (and 
human nature) deceive us. I have a feeling too that the investigator considered how 
much more data we'd need before the existence of non-random data would even show up in 
the statistical test - after all, sample size has to improve by a factor of 4 before 
such confidence tests  improve by a factor of 2.

Whatever the answer, 38 sure wasn't enough data, and the indication seems to be we'd 
need to discover a great deal more before we could even conclude what we were looking 
at isn't just Poisson randomness.

Chris



_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 14:44:09 -0400
From: Jud McCranie <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Islands of Truth

At 01:55 PM 10/14/99 -0400, [EMAIL PROTECTED] wrote:

 > The results were the usual statistical double-talk... e.g. "There is not 
enough evidence to suggest that the (logarithmic) gaps do *not* follow a 
Poisson distribution".

That's not double-talk - that's the way the process works.



+---------------------------------------------------------+
|     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, 14 Oct 1999 14:43:50 -0500
From: "Griffith, Shaun" <[EMAIL PROTECTED]>
Subject: Mersenne: Vaxen & Intel

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

- ------_=_NextPart_001_01BF167C.74143DD2
Content-Type: text/plain;
        charset="iso-8859-1"

Didn't some Vaxen come with vector array processors? Wouldn't this speed up
some aspects of the LL testing (such as frequency domain squarings)?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Shaun Griffith, Texas Instruments MSP Multimedia, [EMAIL PROTECTED] 
work (972)480-2186, fax (972)480-3555, pager (972)598-6823 
alpha pager: page shaun <mailto:[EMAIL PROTECTED]?subject=pageshaun> 
Quantum Mechanics: The dreams stuff is made of

- ------_=_NextPart_001_01BF167C.74143DD2
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>Mersenne: Vaxen &amp; Intel</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Didn't some Vaxen come with =
vector array processors? Wouldn't this speed up some aspects of the LL =
testing (such as frequency domain squarings)?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT=
>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Shaun Griffith, Texas =
Instruments MSP Multimedia,</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">[EMAIL PROTECTED]</FONT></U><FONT SIZE=3D2 =
FACE=3D"Courier New"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">work (972)480-2186, fax =
(972)480-3555, pager (972)598-6823 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">alpha pager:</FONT> <A =
HREF=3D"mailto:[EMAIL PROTECTED]?subject=3Dpageshaun"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">page =
shaun</FONT></U></A>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Courier New">Quantum =
Mechanics:</FONT><FONT SIZE=3D2 FACE=3D"Courier New"></FONT> <FONT =
COLOR=3D"#008000" SIZE=3D2 FACE=3D"Courier New">The dreams stuff is =
made of</FONT>
</P>

</BODY>
</HTML>
- ------_=_NextPart_001_01BF167C.74143DD2--
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 17:29:08 -0400 (EDT)
From: Lucas Wiman  <[EMAIL PROTECTED]>
Subject: Re: Mersenne: DOSville

> .TXT files are the one true document file. Pure ASCII.... bring it on!
> Mathematical notation in .TXT isn't easy, though. It's a conspiracy.

It works well enough.  Most of it is pretty standard, and TeX fills in
the rest
$$\int_{0}^{1}\sqrt{1-x^2}dx={\pi \over 4}$$
Yeah!

> <<FOR GOD SAKE GIVE ME A USER FRIENDLY INTERFACE, PROPER HELP MENU....>>
> 
> Give me a DOS-based command line (yet Win98 background-running capability) 
> with a really nasty, God-awful set of fifteen switches that must be ordered 
> in a precise way depending on the phase of the moon. :-P

Sorry, but M$ didn't invent multitasking, and from what I've seen
(I haven't seen NT multitask much) they have yet to implement it effectivly.
BTW, if you love command line programs with obscure switches, you could
try Linux.

> S. "Property of Billy and Andy" L.

- -Lucas "I owe Linus a case of beer by now" Wiman
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 17:28:42 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Mlucas: Alpha/Linux timings and Solaris 2.6 binary

Bill Rea sent me the Mlucas binary and RTL files for SPARC Solaris 2.6.
SPARC users will want to get

ftp://209.133.33.182/pub/mayer/README

and one of the followiing:

ftp://209.133.33.182/pub/mayer/bin/SPARC/SOLARIS2.6/Mlucas_2.7y.tar.gz
ftp://209.133.33.182/pub/mayer/bin/SPARC/SOLARIS7/Mlucas_2.7y.tar.gz

The SPARC timings indicate that except for exponents in the range
8.95M-~9.4M (and some other small ranges where the two codes are about
equal), users should realize a gain by using Mlucas in place of MacLucasUNIX.

I also have a more-complete set of timings done by Brian Beesley on his
533MHz Alpha/Linux system.
(ftp://209.133.33.182/pub/mayer/bin/ALPHA_LINUX/Mlucas_2.7y.tar.gz):
Note that the RPI percentages given for MacLucasUNIX in the table I posted
yesterday were incorrect - the corrected numbers are included below.

***ALPHA/LINUX TIMINGS***

Program, platform, cache sizes / seconds per iteration (Performance index%)

        Prime95.19 Mlucas2.7y MacLucasUNIX 6.25
        Intel      Alpha      Alpha
        PII/400    PC164/533  PC164/533
        8KB L1     8KB L1     8KB L1
        512KB L2   96KB L2    96KB L2
                   2MB L3     2MB L3
length  ---------- ---------- ----------
  96K   .045       .035 (96%)  n/a
 112K   .055       .045 (92%)  n/a
 128K   .060       .057 (79%) .064 (70%)
 160K   .083       .079 (79%)  n/a
 192K   .098       .099 (74%)  n/a
 224K   .119       .126 (71%)  n/a
 256K   .132       .147 (67%) .156 (63%)
 320K   .173       .188 (69%)  n/a
 384K   .211       .235 (67%)  n/a
 448K   .252       .281 (67%)  n/a
 512K   .281       .314 (67%) .320 (66%)
 640K   .372       .388 (72%)  n/a
 768K   .453       .472 (72%)  n/a
 896K   .536       .575 (70%)  n/a
1024K   .600       .657 (68%) not run
1280K   .776       .886 (66%)  n/a
1536K   .934       1.13 (62%)  n/a
1792K   1.11       1.36 (61%)  n/a
2048K   1.23       1.56 (59%) not run
2560K   1.64       1.91 (64%)  n/a
3072K   1.99       2.32 (64%)  n/a
3584K   2.38       2.79 (64%)  n/a
4096K   2.60       3.19 (61%) not run

_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 18:14:41 -0400
From: "St. Dee" <[EMAIL PROTECTED]>
Subject: Mersenne: Mprime in dual cpu setup?

Hi,

I'm running mprime (v19) on a dual-processor box (RH 6.0, very basic, no
graphical interface at installed) and am curious about the hit others take
when moving from using one to two processors.  (People running duals under
NT are also welcomed to respond!)

If I run a single instance of mprime, I get LL iteration times on exponents
near 8,200,000 of about .220.  If I run two instances of mprime, each gets
iteration times of around .245.  I expected some hit, but I have no idea if
that is too big of a hit or not.  Curiously, I did notice that when the box
was doing some factoring to 64 bits, it didn't seem to make any difference
in the factoring times whether I had one or two processors crunching.

In case it matters, the box contains 2 Celeron 466 processors on an Abit
BP6 board.  Anyone looking for a big speed bump at low cost, try out a
combo like this!

Thanks in advance,
Kel
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 23:03:07 GMT
From: [EMAIL PROTECTED] (Michael Oates)
Subject: Re: Mersenne: Mprime in dual cpu setup?

Hi,

I have a dual PII 560Mhz with NT and get similar results to you, with both
running an exponent M8332549 ish I get times of .220 for each processor,
with just one running it goes to .196

Also, if one is doing an LL test and the other factoring the LL test will
run at .196

>Hi,
>
>I'm running mprime (v19) on a dual-processor box (RH 6.0, very basic, no
>graphical interface at installed) and am curious about the hit others take
>when moving from using one to two processors.  (People running duals under
>NT are also welcomed to respond!)
>
>If I run a single instance of mprime, I get LL iteration times on exponents
>near 8,200,000 of about .220.  If I run two instances of mprime, each gets
>iteration times of around .245.  I expected some hit, but I have no idea if
>that is too big of a hit or not.  Curiously, I did notice that when the box
>was doing some factoring to 64 bits, it didn't seem to make any difference
>in the factoring times whether I had one or two processors crunching.
>
>In case it matters, the box contains 2 Celeron 466 processors on an Abit
>BP6 board.  Anyone looking for a big speed bump at low cost, try out a
>combo like this!
>
>Thanks in advance,
>Kel
>_________________________________________________________________
>Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
>Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

Mike,

- --
ATLAS CELESTE - Bevis Star Atlas - & "The CD-ROM"
A very rare atlas found at the Godlee Observatory
       http://www.u-net.com/ph/mas/bevis/
 Astronomy in the UK    http://www.ph.u-net.com

_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Fri, 15 Oct 1999 01:03:22 +0200
From: Sturle Sunde <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Mprime in dual cpu setup? 

> If I run a single instance of mprime, I get LL iteration times on exponents
> near 8,200,000 of about .220.  If I run two instances of mprime, each gets
> iteration times of around .245.  I expected some hit, but I have no idea if
> that is too big of a hit or not.  Curiously, I did notice that when the box
> was doing some factoring to 64 bits, it didn't seem to make any difference
> in the factoring times whether I had one or two processors crunching.

I guess you've hit the memory bus' limit.  My experience with MacLucasUNIX 
is that a fast memory bus makes a big difference in speed with the same 
CPU.  I've also noticed that a computer with mprime running on both CPUs 
on maximum nice level are noticeable slower at running any memory IO 
intensive applications at the same time, even when they create virtualy no 
extra load.  One mprime process goes unnoticed under the same conditions.


- -- 
Sturle   URL: http://www.stud.ifi.uio.no/~sturles/   Er det m}ndag i dag?
~~~~~~   MMF: http://www.alladvantage.com/go.asp?refid=BUP399  - St. URLe


_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 19:26:30 -0400
From: "St. Dee" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Mprime in dual cpu setup?

At 23:03 10/14/1999 GMT, Michael Oates wrote:

>I have a dual PII 560Mhz with NT and get similar results to you, with both
>running an exponent M8332549 ish I get times of .220 for each processor,
>with just one running it goes to .196
>
>Also, if one is doing an LL test and the other factoring the LL test will
>run at .196

I've noticed this latter phenomenon also.  I guess this is fairly typical
across OS platforms, then.

Thanks for the response, Michael!

Kel
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Fri, 15 Oct 1999 00:33:53 +0100
From: "Ian L McLoughlin" <[EMAIL PROTECTED]>
Subject: Mersenne: problem with prme95 - spl file

Sorry,
Need help having tried to overwrite version 18 with 19-on an LL
test(Win98).Have All the files and managed to run the test from my last save
file pxxxxxxx -Also have q xxxxxxx It initially restarted it.from
scratch...irksome...and downloaded about 10 factorization exponents, when I
just wanted to update and continue..my initial LL test .I have lost (I think
the spl. file )- having been resigned to dragging and dropping files into
the old folder. and deleting old versions... My computer will not update
progress to the primeserver...just keeps sending computer update and user
info...no update on my numerical test..?
Any ideas please?!
Confused...spl files??? how can I create one?
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, 14 Oct 1999 20:44:16 -0400 (EDT)
From: Darxus <[EMAIL PROTECTED]>
Subject: Mersenne: types of work to request - 10m digit prime vs. next prime

As soon as I heard that there was a $100,000 prize available for finding a
prime, I decided to switch to the 10m digit test, even though my chances
of finding it were extreemly small.  I mean, the tiny chance of winning
that cash is better than leaving your idle CPU time idle, right ?

Unfortunately, this cash prize had clouded my thoughts, as I fortunately
realized when my girlfriend told me she opted not to switch to the 10m
digit tests, because she was more interested in getting her name in the
history books than getting $100,000, and there was is a significantly
greater chance of finding the next prime than there is of finding the 1st
10m digit prime.  

That's one of 2 reasons I think this prize money was set up badly.

The second is that I think it will result in more people getting
frustrated, giving up, and quitting, than it will incourage people to
participate and get the program running on more computers, because of the
fact that it takes about 2 years to check one number for primality on pII,
and numbers cannot be split up and tested by multiple computers
simultaneously.  

It was what, half a million dollars total ?  I think it would have been
much better to award $25k per new prime discovered for the next 20 primes.
 
__________________________________________________________________
PGP fingerprint = 03 5B 9B A0 16 33 91 2F  A5 77 BC EE 43 71 98 D4
            [EMAIL PROTECTED] / http://www.op.net/~darxus
          Join the Great Internet Mersenne Prime Search
                http://www.mersenne.org/prime.htm


_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 21:12:22 -0400 (EDT)
From: Darxus <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Islands of Truth

On Thu, 14 Oct 1999 [EMAIL PROTECTED] wrote:

> missing. #2: That the discovered M38, which all we knew about was that it was 
> in the 6M range, was actually around 6.9M, which I was correct about, and #3: 

How did you make this estimate ?  Fit an exponential curve to the known
primes, and extrapolate the 1st one that should have at least 1m digits ?

I think I used to know how to do that, unfortunately at this point I have
little idea.

Why isn't something like this used in GIMPS to select numbers to work on ?
- -- use current known primes to estimate the location of the next, start
allocating numbers to work on at that number, and keep alternating +/-1
till it's found.... ?

__________________________________________________________________
PGP fingerprint = 03 5B 9B A0 16 33 91 2F  A5 77 BC EE 43 71 98 D4
            [EMAIL PROTECTED] / http://www.op.net/~darxus
          Join the Great Internet Mersenne Prime Search
                http://www.mersenne.org/prime.htm


_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 21:15:10 -0400 (EDT)
From: Darxus <[EMAIL PROTECTED]>
Subject: Mersenne: # of digits in 2^p-1

What's the best way of finding the number of decimal digits for the number
2^p-1 ?

__________________________________________________________________
PGP fingerprint = 03 5B 9B A0 16 33 91 2F  A5 77 BC EE 43 71 98 D4
            [EMAIL PROTECTED] / http://www.op.net/~darxus
          Join the Great Internet Mersenne Prime Search
                http://www.mersenne.org/prime.htm


_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 22:29:58 -0400 (EDT)
From: Darxus <[EMAIL PROTECTED]>
Subject: estimating primes (was: Re: Mersenne: Islands of Truth)

On Thu, 14 Oct 1999, Darxus wrote:

> On Thu, 14 Oct 1999 [EMAIL PROTECTED] wrote:
> 
> > missing. #2: That the discovered M38, which all we knew about was that it was 
> > in the 6M range, was actually around 6.9M, which I was correct about, and #3: 
> 
> How did you make this estimate ?  Fit an exponential curve to the known
> primes, and extrapolate the 1st one that should have at least 1m digits ?

Okay, I figured out how to do exponential extrapolation in Excel.

Omitting the 38th prime (p=6,972,593), and exponentially extrapolating
from the 1st through 37th primes, I got the folowing:

       P        digits
#38 5,014,947 1,408,773
#39 7,414,614 2,070,471

Which is... intresting.  

The # of digits extrapolated for #39 (p=7414614) is only 1.36% different
from the actual number of digits in 2^6972593-1.  I wish I had time
tonight to remove more entries and see if this extrapolation continued to
be this accurate.

Also, if this extrapolation of the number of digits is accurate, there is
another prime between the 37th & 38th(p=6972593) discovered primes.

Unfortunately, the extrapolation of P just didn't go well.  Actually, the
extrapolated 39th mersenne prime is 6.34% off of 2^6972593-2.  I suppose
that's not so bad.  That would also mean one was skipped.

So it is currently my fairly strong opinion that a mersenne prime was
skipped between the 37th & 38th discovered primes.  I reserve the right to
change my mind at any instant :)

I'd also guess that the skipped prime may have been pretty close to
2^5014947-1, and have a number of digits close to 1408773.


So does any of this sound at all valid ?

Most people seem to agree that the distribution of mersenne primes is at
least roughly exponential, and that the variances are truly random.  The
above is based on these asumptions.

I don't actually agree with those asumptions, but the distribution fits an
exponential curve better with those assumptions than if you graph them as
pairs.


[EMAIL PROTECTED]: I'm really looking forward to hearing how you made your
estimates.


Hmm... I just changed my worktodo.ini to Test=5014947,63 (where's the 63
come from ?  it was used for the last number I was assigned).

It's saying "Error: Work-to-do file contained composite exponent: 5014947"

I suppose that means it's already been tested & found to be non-prime ?
(composite = non-prime, right?)

I think that manual & primenet should not be seperate optinos on the test
menu.  I think manual should be another option on the "type of work to
request" box. 
__________________________________________________________________
PGP fingerprint = 03 5B 9B A0 16 33 91 2F  A5 77 BC EE 43 71 98 D4
            [EMAIL PROTECTED] / http://www.op.net/~darxus
          Join the Great Internet Mersenne Prime Search
                http://www.mersenne.org/prime.htm



_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 22:31:34 -0400 (EDT)
From: Lucas Wiman  <[EMAIL PROTECTED]>
Subject: Re: Mersenne: # of digits in 2^p-1

> What's the best way of finding the number of decimal digits for the number
> 2^p-1 ?

> Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers
                 ^^^         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Q5.3.  It's no good unless people read it!

- -Lucas
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Thu, 14 Oct 1999 22:37:55 -0400 (EDT)
From: Lucas Wiman  <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Islands of Truth

> > missing. #2: That the discovered M38, which all we knew about was that it was 
> > in the 6M range, was actually around 6.9M, which I was correct about, and #3: 
> 
> How did you make this estimate ?  Fit an exponential curve to the known
> primes, and extrapolate the 1st one that should have at least 1m digits ?

Who knows the misterious ways of STL?

> Why isn't something like this used in GIMPS to select numbers to work on ?
> -- use current known primes to estimate the location of the next, start
> allocating numbers to work on at that number, and keep alternating +/-1
> till it's found.... ?

The verious conjectures all state something about the *average* 
distribution of Mersenne primes.  They don't say anything about the
local distribution.

- -Lucas
_________________________________________________________________
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 #643
******************************

Reply via email to