Mersenne Digest         Friday, June 11 1999         Volume 01 : Number 572




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

Date: 09 Jun 1999 22:49:36 +0200
From: [EMAIL PROTECTED] (Rene H. Larsen)
Subject: Mersenne: Re: Self-test (was: Prime 95 Error Messages/ Misc)

"Pierre Abbat" <[EMAIL PROTECTED]> writes:

> > Most modern motherboards contain case and/or CPU temperature 
> > sensors which can be read by software.
> 
> Is there a file in /proc that will tell me this?

It's not part of the standard kernel yet, but take a look at
<http://www.lm-sensors.nu/>.

HTH.
- -- 
       /'"`\  zzzZ  | My PGP Public Key is available at:
      ( - - )       | <http://home1.inet.tele.dk/renehl/>
- --oooO--(_)--Oooo------------------------------------------ 
 Don't ya just hate it when there's not enough room to fin 

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Wed, 09 Jun 1999 21:55:27 -0500
From: kilfoyle <[EMAIL PROTECTED]>
Subject: Re: Mersenne: These go to 11 (WAS: blahblah...)

APL .. now that brings back memories!    I was an APL wizard in the '70s
regards,
Michael...

Joth Tupper wrote:

> Ground rules are critical, but how about
>
> /.1
>
> where "/" represents the APL-style monadic divide or multiplicative inverse.
>
> 1/.1
>
> takes two.
>
> ----- Original Message -----
> From: Ernst W. Mayer <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 08, 1999 11:47 AM
> Subject: Mersenne: These go to 11 (WAS: blahblah...)
>
> >
> > Paul Leyland <[EMAIL PROTECTED]> wrote:
> >
> > >The radix is always 10.
> > {snip}
> > >or, more concisely, (1+1+1)^(1+1) + 1.
> > >
> > >Can anyone represent that number in fewer than (1+1+1)! ones?
> >
> > How about
> >
> >   1 << 1,
> >
> > where the shift is, of course, decimal.
> >
> > Your shifty friend,
> > -Ernst
> > ________________________________________________________________
> > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
> >
>
> ________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Wed, 09 Jun 1999 23:19:25 -0400
From: George Woltman <[EMAIL PROTECTED]>
Subject: Mersenne: Pentium Pro Optimization Help Needed

Hi all,

        I'm trying to optimize prime95 for the Pentium Pro/PII/PIII
architecture.  I'm fairly well versed in various execution units
and latencies, but some mysteries remain.

        Are there any experts in this field - maybe even some Intel
employees - that could improve the code further?  Even one clock 
cycle in a macro that will be executed a few quintillion times is
a big help.

        The new assemply macros are at ftp://entropia.com/gimps/lucas1p.mac
for you to look at.

        Questions:  Why is the code faster when I throw in some
no-ops (actually fxch st(0) instructions)?  How can I force the
CPU to execute the floating point micro-ops in the optimal order?
Does reordering the fstp instructions have any effect?  Are there
other issues I sould consider?

Regards
George - who is looking forward to IA-64 where I am in control of
the opcode scheduling once again.  Not to mention lots of registers!

P.S.    The clock timings were measured using the following loop.  I can
provide more details upon request.
        mov     al, 0
        mov     ecx, 250                ; 1000 iterations
clp1:   disp four_complex_cpm_fft_3 8, 16, 32           ;;; or some other macro
        lea     esi, [esi+64]
        add     al, 256/4
        jnc     clp1
        lea     esi, [esi-256]
        dec     ecx                     ; Check loop counter
        jnz     clp1                    ; Loop if necessary


________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 00:34:47 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Computer speeds & factoring

I have two questions/comments:

Does anyone else remember something from a year or two back (actually may 
still be a modern thing still)?  This company was producing very fast 
computers using ordinary chips and making the computer case into a type of 
freezer, encasing the chip and keeping the chip very cold.  This made the 
computer run faster, I guess by increasing its conduction, and one result I 
recall is getting a 600 MHz DEC Alpha chip to run at around 767 MHz?  Has 
anyone bought this kind of computer, or perhaps done some kind of home 
modification (like all the overclocking)?

My second question, what is a good factoring program for Win98 on a PII 
system that allows you to enter a very large number and attempt to factor it, 
thereby proving it either composite or prime?  Thanks for any help.
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 07:40:54 +0200
From: Petri Holopainen <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Computer speeds & factoring

[EMAIL PROTECTED] wrote:
> 
> Does anyone else remember something from a year or two back (actually may
> still be a modern thing still)?  This company was producing very fast
> computers using ordinary chips and making the computer case into a type of
> freezer, encasing the chip and keeping the chip very cold.  

You must be thinking of KryoTech: http://www.kryotech.com/

- -- Petri Holopainen
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 11:05:55 GMT
From: "Brian J Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: Self-test

> I completely agree with you about the importance of heat on the
> integrity of the CPU chip.  But interestingly enough, heat is
> something I feel I can control (for instance, by adding more or
> bigger fans) and am satisfied about, as long as my system runs
> X hours of self-test, and Y months of Lucas-Lehmer, without
> visible error.

Fair enough ...
> 
> I feel less reassured about "hidden" influences which are less
> directly under my control:
> 
>  - Though I participate in GIMPS, I'm using neither Windows
>    nor an Intel CPU chip.  All I can hope for is that my setup
>    is as 'accurate' as the one prime95 was designed for.

Presumably you're running Linux (or some other variant of unix) on 
an AMD chip. Or just possibly Cyrix.

The FFT code in mprime is the same as the FFT code in Prime95, 
so you really don't have much to worry about there. Whilst AMD 
CPUs may have different undetected bugs in them to Intel CPUs, 
at least practical experience indicates that systematic errors from 
different CPU types are very rare. This is why we do double-
checking - with the different offset, the data being worked on will 
not be the same, and systematic errors in the CPU (or, for that 
matter, branches in the code which aren't oftem followed) will be 
detected by the final residual being different.
> 
>  - From time to time I make changes to my internal system
>    components.  Who is to say that a new adapter card,
>    for example, will not affect the timings and/or phase
>    relationships of the system's internal signals?
> 
Yes. It can happen. I believe (and have said so before now) that 
you should re-run the selftest if you change anything major in your 
system - CPU, memory, operating system and particularly the 
version of mprime/Prime95. You can force this by deleting the 
"SelfTest" lines in local.ini
> 
> As far as making the self-test more rigorous, I don't know enough
> about the internal workings of FFTs, etc.  But applications are
> often tested by submitting the largest possible value, and the
> smallest possible value, and values which will exercise the most
> decision points.  For GIMPS, such "boundary" conditions might be
> in working with the most 'binary ones' or the most 'binary zeros'
> or the most 'carries' or the longest strings of 'binary ones
> alternating with binary zeros', or with values selected to cause
> the greatest change in the residue from one iteration to the next.

Experiments indicate that "all ones" and "all zeros" are 
exceptionally easy on the code. I suspect that we just don't know 
(& find it very hard to predict) which data patterns will be most 
difficult. The LL test itself, after the first few dozen iterations, 
generates pretty random-looking data (but remember, as Knuth 
points out, you can't generate true random data by a deterministic 
process!). In conjunction with the "scrambling" effect of different 
offsets, running a few hundred iterations of particular (suitably-
chosen) exponents is probably as good a way as any of testing the 
FFT code.

The FFT data consists of a lot of bits (at least as many bits as 
there are in the Mersenne number being tested) so it clearly isn't 
practical to test more than a minute proportion of the possible 
"input" values.


Regards
Brian Beesley
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 00:22:22 +0200
From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
Subject: Mersenne: Further explanation of the v17 bug?

Hi all,

After the discussion on the v17 bug, I wondered if I could get some more info
on it (preferrably to avoid doing such mistakes myself :-) ). I've only heard
it referred to as the `shift bug', and I've picked up that v17 was only
required if you wanted to double-check `your own results'. (?) Does that mean
the error only occurred in double-checking? Was the bug a direct consequence
of the double-checking implementation, or a pure (minor) glitch? BTW, why
couldn't v16 do double-checking?

/* Steinar */
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 10:07:32 -0700
From: "Gilmore, John (AZ75)" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Pentium Pro Optimization Help Needed

>       The new assemply macros are at ftp://entropia.com/gimps/lucas1p.mac
> for you to look at.
> 
        [Gilmore, John (AZ75)]  
        I looked - and I am truely impressed.  I am slightly conversant in
x86 assembly language, and this stuff made my eyes hurt.
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 18:01:59 -0400
From: "Don Leclair" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Pentium Pro Optimization Help Needed

Hi George,

> I'm trying to optimize prime95 for the Pentium
> Pro/PII/PIII architecture.  I'm fairly well
> versed in various execution units and
> latencies, but some mysteries remain.

In case you haven't run across it yet, you can download the "Intel
Architecture Optimizations Manual" from this web page:

http://developer.intel.com/design/pro/MANUALS/242816.htm

It comes in the form of an Acrobat PDF file and includes a good deal
of helpful information for the Pro/PII/PIII including "Chapter 5
Optimization Techniques for Floating Point Applications" which may be
of particular assistance.

For general coding on the Pro/PII/PIII, the three most important
optimizations seem to be:

1) Helping the branch prediction algorithm to guess better.  This can
involve reducing the number of branches or using new instructions such
as CMOV to eliminate some of them altogether.

2) Avoiding partial register stalls.  Partial register stalls occur
when you write to a 8 or 16 bit register and read from the 32-bit
equivalent (e.g. MOV AX, 1;  ADD ECX, EAX)

3) Aligning data structures on 32-byte boundaries.  According to the
docs, a misaligned read on a Pentium costs 3 cycles but costs 6 to 9
on the Pro, II and III (go figure).

The optimization guide is packed full of tips.  It's about 150 pages
in total, although half of it is a reference guide.

- -Don Leclair


________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 18:52:15 -0400
From: "Ernst W. Mayer" <[EMAIL PROTECTED]>
Subject: Mersenne: Whither goest thou, Alpha? (Was: EFF and 10,000,000 digits)

David Willmore writes:
>
>> 2) Was it Intel that bought the Alpha rights?  It might have been IBM but
>> was NOT Compac.
>
>2) Yes, it was Compaq.  Intel bought foundry technology that is used on the
>StrongARM as well as the StrongARM archetecture itself.

Actually, things are tad more complicated than that. http://www.alphapowered.com/
says:

"Engineering design of the Alpha processor remains with Compaq Computer Corp."
...

"Alpha Processor, Inc. was formed in June 1998 by Samsung Electronics Company (SEC) as
an independent company dedicated to the marketing and technical support of the Alpha
microprocessor architecture."

"The new company assures Alpha's continuing success in the Windows NT market. As an
independent Alpha architecture licensee, API will engineer new derivatives to the Alpha
microprocessor by developing innovative high-end workstation and enterprise class 
server
solutions for the marketplace. Compaq's commitment to build Alpha-based systems, and
Microsoft's plans to provide complete operating system and development support for 
Alpha
at parity with any other microprocessor, provides a strong foundation for the company's
success."

With Samsung involved, perhaps we'll soon be seeing Alpha-powered microwave ovens?
I seem to recall a long-buried thread on this list about how long various processors
take to cook a Turkey...(screams of "Nooo! Not that again!" in the background :)

Thanks to David Willmore (not a turkey by any means), I've had a chance to try a soon-
to-be-released update of my Mersenne code on a 500MHz Alpha 21264s, and it's extremely
impressive - 0.18 seconds per iteration at FFT length 384K, fully three times faster
than on my 400MHz 21164.

My code benefits inordinately from good prefetching, and the 21264 is much better at
that than previous versions. The performance on the 21264 is in line with the MIPS
(0.30 seconds on 300 MHz R12000 at FFT length 384K), which means that the longstanding
(see e.g. the SPECFP95 numbers) factor-of-2 difference between the Alpha and MIPS
(when adjusted for the differing clock rates) seems to have been wiped out. No wonder
MIPS doesn't list any performance comparisons with 21264 in their R12000 processor
information sheets (http://www.sgi.com/octane/images/octane.pdf) - 21264 blows them
away, and costs less. (On the other hand, one can upgrade an R10000 to R12000 via
simple chip swap, which one cannot do with the various Alpha generations.)

- -Ernst
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Wed, 09 Jun 1999 23:31:44 -0400
From: Chris Nash <[EMAIL PROTECTED]>
Subject: Mersenne: M38, SETI, and other random stuff

Hi folks,

As we all impatiently await verification of M38(?) a really stupid thought
occurred to me, so apologies if it's a lot more ignorant than Chuck W.'s
"definitive" post on the subject of GIMPS v SETI, or distributed computing
in general.

If the verification of M38 is making us impatient, how on earth would we
feel if SETI did find E.T., and we had to wait thousands of years for our
reply to get back? And, if we send M1, M2, M3.... M38 as proof of our
intelligence, what will *their* comparative results be by the time the
message arrives?

My apologies for being so inane, but I wonder whether the EFF *b*illion
digit prime prize or SETI will happen first, too...

Chris Nash
Lexington KY
UNITED STATES
=======================================================
Co-discoverer of probably the 8th and 11th largest known primes.

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 21:01:52 -0400
From: Jud McCranie <[EMAIL PROTECTED]>
Subject: Mersenne: status of exponents

The status page shows that for exponents in the range 3,310,000-3,960,000,
there are 225 exponents for which 2 L-L tests have been done, yet there are
40 exponents for which no factor is known, and no LL test has been done.  I
have 2 questions:

1.  Why have 2nd LL tests been done in many cases when there are still
exponents whose status is unknown?

2. Exponents over 6,000,000 have been assigned for a couple of months or
so.  Why are large exponents being assigned when there are still smaller
ones in need of a LL test?

+----------------------------------------------+
| Jud "program first and think later" McCranie |
+----------------------------------------------+


________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 21:22:48 EDT
From: [EMAIL PROTECTED]
Subject: Re: Mersenne: status of exponents

In a message dated 6/10/99, 9:07:19 PM, [EMAIL PROTECTED] writes:
> The status page shows that for exponents in the range 3,310,000-3,960,000,
> there are 225 exponents for which 2 L-L tests have been done, yet there are
> 40 exponents for which no factor is known, and no LL test has been done.  I
> have 2 questions:
>
> 1.  Why have 2nd LL tests been done in many cases when there are still
> exponents whose status is unknown?

I would venture to say that those 40 exponents are "out" at the moment, 
assigned to machines which have not yet turned in a result.  

> 2. Exponents over 6,000,000 have been assigned for a couple of months or
> so.  Why are large exponents being assigned when there are still smaller
> ones in need of a LL test?

The same reason as #1.
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 18:26:48 -0700
From: "Gilmore, John (AZ75)" <[EMAIL PROTECTED]>
Subject: RE: Inane Stuff (Was: Mersenne: M38, SETI, and other random stuff )

My vote for "Most Inane" would be to the guy a year or two ago who claimed
to know for an absolute certainty that there were only, (I think it was) 37
Mersenne primes.  Whatever the number was, it was about one more than had
been discovered at that point.

> -----Original Message-----
> From: Chris Nash [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, June 09, 1999 8:32 PM
> To:   [EMAIL PROTECTED]
> Subject:      Mersenne: M38, SETI, and other random stuff
> 
> Hi folks,
> 
> As we all impatiently await verification of M38(?) a really stupid thought
> occurred to me, so apologies if it's a lot more ignorant than Chuck W.'s
> "definitive" post on the subject of GIMPS v SETI, or distributed computing
> in general.
> 
> My apologies for being so inane, but I wonder whether the EFF *b*illion
> digit prime prize or SETI will happen first, too...
> 
> Chris Nash
> Lexington KY
> UNITED STATES
> =======================================================
> Co-discoverer of probably the 8th and 11th largest known primes.
> 
> ________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 19:49:16 -0700
From: "Gilmore, John (AZ75)" <[EMAIL PROTECTED]>
Subject: RE: Inane Stuff (Was: Mersenne: M38, SETI, and other random stuff )

> > -----Original Message-----
> > From:       Chris Nash [SMTP:[EMAIL PROTECTED]]
> > Sent:       Wednesday, June 09, 1999 8:32 PM
> > To: [EMAIL PROTECTED]
> > Subject:    Mersenne: M38, SETI, and other random stuff
> > 
> > My apologies for being so inane, but I wonder whether the EFF *b*illion
> > digit prime prize or SETI will happen first, too...
> 
        [Gilmore, John (AZ75)]  Unless someone comes up with a MUCH faster
        algorithm, or a parallelizable algorithm, since a 90 GHz Pentium
would
        take (to one significant figure) 80 years to test _one_ exponent, my
guess
        would be SETI (assuming, of course, that there actually _is_ ETI out
there)

        I'm not counting on seeing either in my lifetime.
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 21:36:11 -0600
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: RE: Inane Stuff (Was: Mersenne: M38, SETI, and other random stuff )

>       [Gilmore, John (AZ75)]  Unless someone comes up with a MUCH faster
>       algorithm, or a parallelizable algorithm, since a 90 GHz Pentium
> would
>       take (to one significant figure) 80 years to test _one_ exponent, my
> guess
>       would be SETI (assuming, of course, that there actually _is_ ETI out
> there)

I assume you meant 90 MHz, not GHz.  Who knows, we might actually see 90GHz
processors (in my lifetime anyway...I'm still sort of a young sprout :-), in
which case you'd be testing MUCH faster, yes?

Even with a nice 550MHz PIII, a 33M exponent could be tested in maybe around
1/12 the time of a P90 (about 6 times faster, as well as being much more
optimized...maybe more like 1/10).  I think 80 years is a bit of an
overestimate though...but I could be wrong on that.

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 22:22:15 -0700
From: Spike Jones <[EMAIL PROTECTED]>
Subject: Re: Mersenne: M38, SETI, and other random stuff

Chris Nash wrote:

> If the verification of M38 is making us impatient, how on earth would we
> feel if SETI did find E.T., and we had to wait thousands of years for our...

If SETI found a signal, antennae all over the planet would focus on it
and large numbers of brains would consume themselves trying to sort
out and interpret the messages.

I am one who would *immediately* drop my job like a red hot
horseshoe and devote my full attention exclusively to the task.
I make no apology, and I am quite serious.  I would consider
it far more important than anything else I could do.

In the meantime, I am happy to search for the next Mersenne
prime, and find lots of Mersenne composites.  spike

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Thu, 10 Jun 1999 22:27:29 -0700
From: Colin Percival <[EMAIL PROTECTED]>
Subject: RE: Inane Stuff (Was: Mersenne: M38, SETI, and other random stuff )

At 07:49 PM 10/06/99 -0700, you wrote:
>> > My apologies for being so inane, but I wonder whether the EFF *b*illion
>> > digit prime prize or SETI will happen first, too...
>> 
>       [Gilmore, John (AZ75)]  Unless someone comes up with a MUCH faster
>       algorithm, or a parallelizable algorithm, since a 90 GHz Pentium
> would take (to one significant figure) 80 years to test _one_ exponent, my
> guess would be SETI (assuming, of course, that there actually _is_ ETI out
> there)

  On a Pentium 90, testing a single billion digit mersenne number would
take 3.3 billion iterations @ around 15 minutes each (with sufficient
memory!), meaning about 1500 years.
  There are about 150 million primes less than 3.3*10^9, and at the current
rate, we seem to do LL tests on 1/3 of them.
  So we are about 7.5*10^10 P90 years away from our first billion digit prime.
  Following conservative estimates of cpu power and number of participants
doubling every two years, I'd guess that we will have a our first billion
digit prime in 2021, when we have 40 million participants and Pentium XV
1000GHz processors.

>       I'm not counting on seeing either in my lifetime.

  Well, I still plan on seeing it in my lifetime. ;-)

Colin Percival

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 06:31:22 -0400 (EDT)
From: "St. Dee" <[EMAIL PROTECTED]>
Subject: RE: Inane Stuff (Was: Mersenne: M38, SETI, and other random  stuff )

On Thu, 10 Jun 1999, Colin Percival wrote:
>
>   So we are about 7.5*10^10 P90 years away from our first billion digit prime.
>   Following conservative estimates of cpu power and number of participants
> doubling every two years, I'd guess that we will have a our first billion
> digit prime in 2021, when we have 40 million participants and Pentium XV
> 1000GHz processors.

Scott, do you have plans in place to ramp up the PrimeNet servers to
handle these 40 million participants?  :-)

Kel

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 09:43:44 -0300 (EST)
From: "Nicolau C. Saldanha" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: M38, SETI, and other random stuff

On Wed, 9 Jun 1999, Chris Nash wrote:

> Hi folks,
> 
> As we all impatiently await verification of M38(?) a really stupid thought
> occurred to me, so apologies if it's a lot more ignorant than Chuck W.'s
> "definitive" post on the subject of GIMPS v SETI, or distributed computing
> in general.
> 
> If the verification of M38 is making us impatient, how on earth would we
> feel if SETI did find E.T., and we had to wait thousands of years for our
> reply to get back? And, if we send M1, M2, M3.... M38 as proof of our
> intelligence, what will *their* comparative results be by the time the
> message arrives?

Talking about impatience, there is something I don't understand:
are we waiting just for the doublecheck to be completed or does the
EFF prize somehow require that M38 be kept secret until publication?
I hope not, that would be very strange indeed...

http://www.mat.puc-rio.br/~nicolau

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 09:16:43 -0400
From: Jud McCranie <[EMAIL PROTECTED]>
Subject: Re: Mersenne: status of exponents

At 09:22 PM 6/10/99 -0400, [EMAIL PROTECTED] wrote:

>I would venture to say that those 40 exponents are "out" at the moment, 
>assigned to machines which have not yet turned in a result.  

But I thought that the exponents were reassigned if no result was reported in 2
months.  These were assigned much more than 2 months ago.

+----------------------------------------------+
| Jud "program first and think later" McCranie |
+----------------------------------------------+


________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: 11 Jun 99 07:53:13 MDT
From: Paul Derbyshire <[EMAIL PROTECTED]>
Subject: Re: Mersenne: status of exponents

Jud McCranie <[EMAIL PROTECTED]> wrote:

[Mysterious missing Mersenne exponents]

> But I thought that the exponents were reassigned if no result was
> reported in 2 months.  These were assigned much more than 2 months ago.

No, they're reassigned if no update is reported in 2 months. The update may be
a keepalive or an expected completion date or almost anything.

Some exponents take much longer than 2 months to LL test on slower machines.
Those are probably just whichever 3M-area exponents got assigned to 286s and
386s :-)


____________________________________________________________________
Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 10:32:21 -0400
From: Jeff Woods <[EMAIL PROTECTED]>
Subject: Re: Mersenne: status of exponents

Exponents are only re-assigned if the machine they are assigned to has not 
been heard from AT ALL over the past 60 days.   So long as the machine 
checks in and tells PrimeNet that it is still working, it will let them 
take as long as they want to check the exponent.

This was my complaint from a couple days ago -- one client in particular 
has four exponents checked out for double-checking, and is regularly 
checking in -- taking 11 months to check a single exponent.   Even though 
those three "untouched" exponents won't even be LOOKED AT by the machine 
for up to three years, the will never expire because the machine checks in 
regularly (at least every 60 days) and reports that it did a few iterations.

As I said, unless there is an intervention or someone just takes it upon 
themselves to double-check those exponents with software other than 
George's (the very basis of doublechecking), we won't get confirmation of 
M37 until 2003.... <sigh>

At 09:16 AM 6/11/99 -0400, you wrote:
>At 09:22 PM 6/10/99 -0400, [EMAIL PROTECTED] wrote:
>
> >I would venture to say that those 40 exponents are "out" at the moment,
> >assigned to machines which have not yet turned in a result.
>
>But I thought that the exponents were reassigned if no result was reported 
>in 2
>months.  These were assigned much more than 2 months ago.
>
>+----------------------------------------------+
>| Jud "program first and think later" McCranie |
>+----------------------------------------------+
>
>
>________________________________________________________________
>Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 16:48:20 +0200
From: "Grieken, Paul van" <[EMAIL PROTECTED]>
Subject: Mersenne: personal account report

hello members,
Recently I finished my first exponent testing, hoi hoi hoi, I send the
result.txt manually to the prime server.
In my personal report the exponent was registered, so far ok.
But if I look into my personal report I see that the "LL P90 CPU yrs"
and all the other numbers on the same line like "Exponents LL tested"
are still all on zerro, why??
Did I do something wrong or what.
Please clear this for me, I like to do it in the correct way.
best wishes,

Paul van Grieken
Alcatel Telecom Nederland
afd: T-TAC NE
Postbus 3292
2280GG rijswijk
Nederland

Phone:  + 31 70 307 9353
Fax:      + 31 70 307 9476
Email: [EMAIL PROTECTED]

Prive:
Ruys de Beerenbrouckstraat 1
2613AS Delft
Netherlands

Marklin collector

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 10:58:55 -0400
From: Yvan Dutil <[EMAIL PROTECTED]>
Subject: Re: Mersenne: status of exponents

At 07:53 AM 6/11/99 MDT, Paul Derbyshire wrote:
>Jud McCranie <[EMAIL PROTECTED]> wrote:
>
>[Mysterious missing Mersenne exponents]
>
>> But I thought that the exponents were reassigned if no result was
>> reported in 2 months.  These were assigned much more than 2 months ago.
>
>No, they're reassigned if no update is reported in 2 months. The update
may be
>a keepalive or an expected completion date or almost anything.

The limit is 60 days after the completion date, and not since the last update.
These ones never call back in since more than a year. Four of them will be
still
allocated a year from now.

prime      fact  current          days
exponent    bits iteration  run / to go / exp   date updated     date
assigned 
- -------- -- ---- ---------  -----------------  ---------------
- ---------------
4465127     60             470.2 313.8 373.8                   26-Feb-98 09:23
4671439  *  60             369.8 149.2 209.2                   06-Jun-98 20:31
4787599     61             373.9 664.1 724.1                   02-Jun-98 16:42
4833901     61             401.9 407.1 467.1                   05-May-98 16:35
4864591     61             373.0  34.0  94.0                   03-Jun-98 13:18
4876111     61             411.3  51.7 111.7                   26-Apr-98 07:59
4926563     61             436.6 105.4 165.4                   31-Mar-98 23:58
5016679     61             385.5 383.5 443.5                   22-May-98 02:09
5123693     61             369.6 -43.6  16.4                   06-Jun-98 23:55

Yvan Dutil

________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 09:05:40 -0600
From: "Blosser, Jeremy" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Pentium Pro Optimization Help Needed

Umm... decoding optimization (4-1-1 rule)
For example in four_complex_cpm_fft_3:
;;1-1-1
        fld     R6                      ;; I2,I3,A2,r/i,A4,I1,R3,R1
        fmul    st(3), st               ;; B2 = I2 * r/i
;23-27
        fsubp   st(2), st               ;; A2 = A2 - I2
;24-26
;;1 (D1, D2 stall)
        fld     R8                      ;; I4,I3,A2,B2,A4,I1,R3,R1
;;2-1 (D2 stall)
        fmul    QWORD PTR [edi+24]      ;; B4 = I4 * r/i
;25-29
        fxch    st(4)                   ;; A4,I3,A2,B2,B4,I1,R3,R1
;;2-1 (D2 stall)
        fsub    R8                      ;; A4 = A4 - I4
;26-28
        fxch    st(2)                   ;; A2,I3,A4,B2,B4,I1,R3,R1

Plus all the stores are decoded in separate cycles (2 uOps)
I'm sure someone else will correct my mistakes ;)

I'm sure you checked cache alignments... I can't think of anything else
offhand...

Also, I noticed that no attention was paid to as far as K6 optimization (ie
tossing the fxch's) in the current code... Any effort to improve that or is
it not worth it?

- -----Original Message-----
From: George Woltman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 09, 1999 10:19 PM
To: [EMAIL PROTECTED]
Subject: Mersenne: Pentium Pro Optimization Help Needed


Hi all,

        I'm trying to optimize prime95 for the Pentium Pro/PII/PIII
architecture.  I'm fairly well versed in various execution units
and latencies, but some mysteries remain.

        Are there any experts in this field - maybe even some Intel
employees - that could improve the code further?  Even one clock 
cycle in a macro that will be executed a few quintillion times is
a big help.

        The new assemply macros are at ftp://entropia.com/gimps/lucas1p.mac
for you to look at.

        Questions:  Why is the code faster when I throw in some
no-ops (actually fxch st(0) instructions)?  How can I force the
CPU to execute the floating point micro-ops in the optimal order?
Does reordering the fstp instructions have any effect?  Are there
other issues I sould consider?

Regards
George - who is looking forward to IA-64 where I am in control of
the opcode scheduling once again.  Not to mention lots of registers!

P.S.    The clock timings were measured using the following loop.  I can
provide more details upon request.
        mov     al, 0
        mov     ecx, 250                ; 1000 iterations
clp1:   disp four_complex_cpm_fft_3 8, 16, 32           ;;; or some other
macro
        lea     esi, [esi+64]
        add     al, 256/4
        jnc     clp1
        lea     esi, [esi-256]
        dec     ecx                     ; Check loop counter
        jnz     clp1                    ; Loop if necessary


________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 11:28:23 -0400
From: Yvan Dutil <[EMAIL PROTECTED]>
Subject: Re: Mersenne: status of exponents

At 07:53 AM 6/11/99 MDT, Paul Derbyshire wrote:
>Jud McCranie <[EMAIL PROTECTED]> wrote:
>
>[Mysterious missing Mersenne exponents]
>
>> But I thought that the exponents were reassigned if no result was
>> reported in 2 months.  These were assigned much more than 2 months ago.
>
>No, they're reassigned if no update is reported in 2 months. The update
may be
>a keepalive or an expected completion date or almost anything.


In addition these ones have stay silent for a year:

prime      fact  current          days
exponent    bits iteration  run / to go / exp   date updated     date assigned

4300291 D   61             447.1 -24.8  35.2  21-Mar-98 18:45  21-Mar-98 11:03
4369949     60             473.5 225.9 285.9  22-May-98 13:13  23-Feb-98 02:21

However, these ones seem (somehow) to follow the rule?

prime      fact  current          days
exponent    bits iteration  run / to go / exp   date updated     date assigned

4472627     61   1509116   216.4 196.0  81.0  04-Jun-99 15:27  07-Nov-98 04:35
4692539     61   1337470   163.3 177.8  57.8  08-Jun-99 08:07  30-Dec-98 06:11
4742407     61   3604480   292.8  48.8  53.8  04-Jun-99 10:17  22-Aug-98 19:59
4746997     61              45.3  26.6  60.6  11-Jun-99 04:27  27-Apr-99 06:03
4786079     61               1.3  92.7  86.7  10-Jun-99 06:29  10-Jun-99 06:24
4854439     61   2818048   214.7  52.3  66.3  10-Jun-99 21:41  08-Nov-98 22:46
and many more...

P.S. While I was writing this message, I recieved the message of Jeff Wood
explaning
than the check is machine based and not number base which explained this
behavior.

Yvan Dutil



________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Fri, 11 Jun 1999 10:45:12 -0500
From: "Willmore, David" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Whither goest thou, Alpha? (Was: EFF and 10,000,000 digits)

        Ernst Mayer:
> David Willmore writes:
> >
> >> 2) Was it Intel that bought the Alpha rights?  It might have been IBM
> but
> >> was NOT Compac.
> >
> >2) Yes, it was Compaq.  Intel bought foundry technology that is used on
> the
> >StrongARM as well as the StrongARM archetecture itself.
> 
> Actually, things are tad more complicated than that.
> http://www.alphapowered.com/
> says:
> 
> "Engineering design of the Alpha processor remains with Compaq Computer
> Corp."
> ...
> 
> "Alpha Processor, Inc. was formed in June 1998 by Samsung Electronics
> Company (SEC) as
> an independent company dedicated to the marketing and technical support of
> the Alpha
> microprocessor architecture."
> 
> "The new company assures Alpha's continuing success in the Windows NT
> market. As an
> independent Alpha architecture licensee, API will engineer new derivatives
> to the Alpha
> microprocessor by developing innovative high-end workstation and
> enterprise class server
> solutions for the marketplace. Compaq's commitment to build Alpha-based
> systems, and
> Microsoft's plans to provide complete operating system and development
> support for Alpha
> at parity with any other microprocessor, provides a strong foundation for
> the company's
> success."
> 
Okay, the confusion comes in from the fact that DEC used to own the 'design'
of the Alpha and now that has gone to Compaq.  Samsung (and a few others,
Fujitsu?) licensed that design and are allowed to make some changes and have
the right to new designs produced by the owner of the design.  It looks like
Samsung set up a sort of spinoff to hold their rights to the license of the
Compaq owned Alpha design.  Clear? :)

> With Samsung involved, perhaps we'll soon be seeing Alpha-powered
> microwave ovens?
> I seem to recall a long-buried thread on this list about how long various
> processors
> take to cook a Turkey...(screams of "Nooo! Not that again!" in the
> background :)
> 
Yes, there was talk of the Alpha toaster.  When the first gen chips used
40W, people talked about an Alpha SMP toaster oven.  (some kind of pun along
the lines of the sun 'pizza box')

> Thanks to David Willmore (not a turkey by any means), I've had a chance to
> try a soon-
> to-be-released update of my Mersenne code on a 500MHz Alpha 21264s, and
> it's extremely
> impressive - 0.18 seconds per iteration at FFT length 384K, fully three
> times faster
> than on my 400MHz 21164.
> 
Hopefully this will be my redeeming grace for this long and off topic
email--sorry all.

> My code benefits inordinately from good prefetching, and the 21264 is much
> better at
> that than previous versions. The performance on the 21264 is in line with
> the MIPS
> (0.30 seconds on 300 MHz R12000 at FFT length 384K), which means that the
> longstanding
> (see e.g. the SPECFP95 numbers) factor-of-2 difference between the Alpha
> and MIPS
> (when adjusted for the differing clock rates) seems to have been wiped
> out. No wonder
> MIPS doesn't list any performance comparisons with 21264 in their R12000
> processor
> information sheets (http://www.sgi.com/octane/images/octane.pdf) - 21264
> blows them
> away, and costs less. (On the other hand, one can upgrade an R10000 to
> R12000 via
> simple chip swap, which one cannot do with the various Alpha generations.)
> 
Yeah, true, but the 21164 is capable of over 5GB/s of L2 cache
bandwidth(maybe 8+ in the near future), so who needs  MIPS any more.  (sorry
Mr. Mashy)

Cheers,
David
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

End of Mersenne Digest V1 #572
******************************

Reply via email to