Mersenne Digest       Tuesday, February 8 2000       Volume 01 : Number 689




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

Date: Sun, 6 Feb 2000 13:42:58 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: SMP GIMPSing And Sharing The Burden

On 2 Feb 00, at 20:15, Stefan Struiker wrote:

> Does the L-L process lend itself to some parallelization
> (not the running of multiple copies) over N processors?

Not very well.

However, the FFT itself is very amenable to parallel processing 
techniques - on a processor with N independent compute pathways, you 
can compute N elements in the same time that a single element would 
take to compute just one.



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

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

Date: Sun, 6 Feb 2000 14:07:57 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Mersenne: P-1 factoring

I've been reading up on the P-1 method ... am I missing something?

For a Mersenne number 2^n-1 with n prime we know that all the factors 
are of the form 2kn+1 for some integer k. So the factorization of p-1 
_must_ include at least one factor equal to n.

But the text leads me to believe that the P-1 method will only find 
factors when the factorization of P-1 contains no primes greater than 
the search limit.

So, is using P-1 to factor Mersenne numbers with exponents in the 
millions but with B1 ~ 60,000 and B2 ~ 720,000 doomed to failure, or 
is my interpretation of the text completely wrong?

I am (as an experiment) currently running P-1 on 2^11692589-1 using 
B1=60000 and B2=720000. I happen to know that 5318756664776903 ( = 
2*k*11692589+1 for the prime k = 227441359) is a factor of this 
number, it will be interesting to see if P-1 finds it. Trial 
factoring will find this particular factor quite quickly!


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

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

Date: Sun, 6 Feb 2000 06:17:28 -0800 
From: Paul Leyland <[EMAIL PROTECTED]>
Subject: RE: Mersenne: P-1 factoring

> I've been reading up on the P-1 method ... am I missing something?

I don't think so, except perhaps for on possibility...

> 
> For a Mersenne number 2^n-1 with n prime we know that all the factors 
> are of the form 2kn+1 for some integer k. So the factorization of p-1 
> _must_ include at least one factor equal to n.
> 
> But the text leads me to believe that the P-1 method will only find 
> factors when the factorization of P-1 contains no primes greater than 
> the search limit.
> 
> So, is using P-1 to factor Mersenne numbers with exponents in the 
> millions but with B1 ~ 60,000 and B2 ~ 720,000 doomed to failure, or 
> is my interpretation of the text completely wrong?

I believe, or at least sincerely hope, that the text is incomplete.  Every
implementation of P-1 of which I'm aware which is to be used to factor
integers whose factors are known to be of the form kp-1 invariably throw in
an additional k, as well as all the prime powers up to the B1 limit.  (And
likewise for P+1 and factors of the from kp+1).

If the text is not incomplete, someone fix the program!


Paul



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

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

Date: Sun, 6 Feb 2000 16:18:03 +0100 (MET)
From: Wojciech Florek <[EMAIL PROTECTED]>
Subject: Mersenne: Re: The return of poaching

Hi all!
My 2 cents...
> > few are hogging all those exponents for themselves, purely for the
> > satisfaction of watching their stats go up on a day by day basis.
> >
> 
> Did you know that for about 6-8 hours _each_ days, it's only expired
> exponent that are distributed. So about 20 exponent re-released by PrimeNet
> will in there own time expire again (and the cycle begin anew).
The only disadvantage of a method introduced (I think) by diamonddave
and used by me and, probably, some other users is that some not so large
exponents (in my case near 3.5M) are kept assigned to me for two-four
days. Then - luckily - I obtain an exponents near 3M and those larger
are released to pull. I promise to run my shell script only time
to time. Now I have several small exponents and tomorrow will be the last
try to obtain smaller ones. Next I'll finish some of them and then
I'll start my shell script again for a week or two (it is started every
other day). I'll change DaysOfWork to 15.

> > So, my opinion comes down to this:  People who reserve ONLY small
> exponents
> > are doing the project a disservice by not allowing the distributed nature
> of
> > the project to work.  They use a fallacious argument about "keeping them
> out
> > of the hands of the infidels" as justification for it.  Fallacious because
> > that's the job of Primenet's expiration policy.
> 
> What is the difference between keeping only small exponent and keeping only
> big exponent (going for 100,000$), we will reach that plateau eventually?
> 
> Why did this tread went from exposing a poacher to accusing a sensible
> PrimeNet user of poaching? Everyone seemed to have forgotten are mutual
> friend "Rick", why?
> 
> David Campeau a.k.a. DiamondDave
Agree, agree, agree, ...
I'm an impatient person in a way. I like my exponents finished in a few
days. So I've devoted my Celeron 366 and Pentium II 400 (50-70% CPU in
both cases) to the DoubleChecking though they are not so bad in the
first test I think (I've got assigned one 8M for the LL test, it is
in a queue...). 
Regards

Wojtek (WsF)

email: [EMAIL PROTECTED] 
www:   http://spin.amu.edu.pl/~florek


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

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

Date: Sun, 6 Feb 2000 11:12:46 -0500
From: "Geoffrey Faivre-Malloy" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Re: The return of poaching

> I'm an impatient person in a way. I like my exponents finished in a few

Me too :)  That's why I factor.  I've got about 8 machines factoring (from
PII 266 all the way up to PIII 500).  Still...someone has managed to push me
down to number 4 on the factoring top 100.  I'll catch up though!  :)

G-Man

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

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

Date: Sun, 06 Feb 2000 05:37:58 -0600
From: [EMAIL PROTECTED] (Mikus Grinbergs)
Subject: Mersenne: 60 Day Expiration

I've mothballed a middling-speed non-Intel machine.  That machine
could have been participating in GIMPS, but I chose not to have
it do so any more.  The reason - I resent feeling "pressured" by
expiration requirements and contact-every-xx-days requirements.

That machine is not normally connected.  Meaning to contact the
PrimeNet server, I either have to "patch in" through a machine on
a LAN, or use the "manual" web browser forms.  I do not mind doing
so every once in a while - when I can both report the result of
the previous exponent and pick up a new exponent to work on.

As long as processing one exponent took less than 60 days, I was
willing to chance it that my exponent would not be reassigned
before that machine finished it.  But now processing of larger
exponents takes more than 60 days.  I am __NOT__ willing to
double my effort (i.e., make contact when half through) just to
"keep" my exponent from being reassigned.  My solution - stop
participating with that machine.

mikus

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

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

Date: Sun, 6 Feb 2000 17:26:45 +0100
From: "Lars Lindley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: SMP GIMPSing And Sharing The Burden

- ----- Original Message -----
From: Brian J. Beesley <[EMAIL PROTECTED]>

> However, the FFT itself is very amenable to parallel processing
> techniques - on a processor with N independent compute pathways, you
> can compute N elements in the same time that a single element would
> take to compute just one.
>
How much of the mersenne-test is used for the FFT then?
Isn't the FFT the single most time-consuming part?

Wouldn't it make sense to make a parallelized version of prime95 that
distributes the FFT over N processors?

Regards, Lars

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

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

Date: Sun, 6 Feb 2000 10:30:59 -0700
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: SMP GIMPSing And Sharing The Burden

> > However, the FFT itself is very amenable to parallel processing
> > techniques - on a processor with N independent compute pathways, you
> > can compute N elements in the same time that a single element would
> > take to compute just one.
> >
> How much of the mersenne-test is used for the FFT then?
> Isn't the FFT the single most time-consuming part?
>
> Wouldn't it make sense to make a parallelized version of prime95 that
> distributes the FFT over N processors?

I've been down this road before.  The best parallelization you can do is to
run multiple instances of prime, one for each CPU.  Otherwise, it wouldn't
be an optimal use of resources.

If one CPU takes 2 weeks to do an LL test, 2 CPU's working on it in parallel
might get it done in 1.5 weeks.  On the otherhand, if you run 2 instances,
you get *2* numbers done in *slightly* over 2 weeks instead of just 1,
effectively doubling your efforts.

I say slightly over 2 weeks since Prime95/NTPrime running on multiple CPU's
will compete for memory bandwidth and I've seen it slow down to about
96%-98% of it's speed compared to when it's running on only a single CPU.

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

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

Date: Sun, 6 Feb 2000 12:50:39 -0500 (EST)
From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]>
Subject: Re: Mersenne: SMP GIMPSing And Sharing The Burden

On Sun, 6 Feb 2000, Lars Lindley wrote:

> > However, the FFT itself is very amenable to parallel processing
> > techniques - on a processor with N independent compute pathways, you
> > can compute N elements in the same time that a single element would
> > take to compute just one.
> >
> How much of the mersenne-test is used for the FFT then?
> Isn't the FFT the single most time-consuming part?
> 
> Wouldn't it make sense to make a parallelized version of prime95 that
> distributes the FFT over N processors?

Parallel FFTs typically have three steps: 1) crunch like mad on local
data, 2) global scatter-gather (everybody trades data with everybody
else), 3) crunch like mad on local data. In the GIMPS case, you want
an inverse FFT too, so that the order is 12321. With the real FFTs that
Prime95 uses it's worse...step 3 has some global communication too.
The communicaton is much more a problem for systems with distributed
memory, but since speed is of the essence here the communication means
cache thrashing. Running two processors in parallel will speed things up,
but I would think that the speedup wouldn't be as great as running two
copies of Prime95. You could probably get some cool single machine
statistics though :)

Part of the problem here is that to know for sure you'd have to
multithread the code, which would be messy. It would be *really*
interesting to multithread things if your machine performed a context 
switch while waiting for a cache miss (in an effort to do useful work
while the CPU would otherwise be stalled), but I think only a sparc
can context switch that fast.

jasonp

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

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

Date: Sun, 6 Feb 2000 12:34:42 -0800
From: "Joth Tupper" <[EMAIL PROTECTED]>
Subject: Mersenne: Does GIMPS send e-mails to the originator?

this is a test.  again, sorry for the spam.

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

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

Date: Sun, 6 Feb 2000 21:41:14 +0000
From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
Subject: Mersenne: Re: 60 Day Expiration

On Sun, Feb 06, 2000 at 05:37:58AM -0600, Mikus Grinbergs wrote:
>I've mothballed a middling-speed non-Intel machine.  That machine
>could have been participating in GIMPS, but I chose not to have
>it do so any more.  The reason - I resent feeling "pressured" by
>expiration requirements and contact-every-xx-days requirements.

Try sending direct mail to George Woltman ([EMAIL PROTECTED]),
who's the leader of the search. I'm sure he could allocate you
some exponents, with manual (e-mail) check-in and long expiration
dates.

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

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

Date: Sun, 6 Feb 2000 22:38:50 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: SMP GIMPSing And Sharing The Burden

On 6 Feb 00, at 12:50, Jason Stratos Papadopoulos wrote:

> > > However, the FFT itself is very amenable to parallel processing
> > > techniques - on a processor with N independent compute pathways, you
> > > can compute N elements in the same time that a single element would
> > > take to compute just one.
> > >
> > How much of the mersenne-test is used for the FFT then?
> > Isn't the FFT the single most time-consuming part?
> > 
> > Wouldn't it make sense to make a parallelized version of prime95 that
> > distributes the FFT over N processors?

The trouble here is that you need vector processors - not SMP - to do 
the job properly i.e. all the processors share memory so there is not 
really a communication problem.

Actually we already do a bit of interleaving - even on uniprocessor 
systems - to make best use of the processor pipeline & cache line 
characteristics.


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

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

Date: Sun, 6 Feb 2000 18:57:10 -0800
From: Russel Brooks <[EMAIL PROTECTED]>
Subject: Mersenne: Prime95 causes screen jitters

I've got my friend's 450MHz PII Aptiva with 256Meg ram running Prime95
under Win98.  I'm seeing minor interference on the display when Prime is
running.  If I stop Prime the interference stops.  Not much else is
running 99% of the time so it's an ideal GIMPS machine but I'm bothered
by the affect it has on the display.  I've tried all kinds of different
resolutions and sync rates but the ONLY thing that seems to affect it is
whether or not Prime95 is running.

Any ideas? ...suggestions?

Cheers... Russ

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

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

Date: Mon, 07 Feb 2000 10:15:12 -0500
From: Jeff Woods <[EMAIL PROTECTED]>
Subject: Re: Mersenne: 60 Day Expiration

At 05:23 PM 2/6/00 -0600, you wrote:

>What do we have now?  I *do* find it troublesome to contact the
>server to say "I'm still here" - that is "compulsion" rather than
>"trust".  As my post indicated, if I am considered untrustworthy
>for failing to do it, I will simply choose to not participate.

That's not COMPULSION -- it's COMPASSION.   Primenet came about because 
"the good old days" that you yearn for (and I was there, have been since 
April 1996) have grown to the point where it *has* to be automated, as you 
recognized in your post.   However, you can't have your cake and eat it, 
too.  If you're going to automate, you can't automate the assignments and 
not automate the completion.

George DID used to "tickle" folks who'd had exponents out a very long 
time.  (This, back in the day when a single LL test too no more than a 
week, mind you).   He'd send an Email after about THIRTY days IIRC, and if 
no response, he'd reclaim and recycle them by hand, just exactly like 
Primenet does now.

OLD:

If a checked out exponent wasn't reported within a reasonable time...
   George manually sent Email to ask "Are you still working on this?"
   If the answer was yes, the exponents continued to be left alone.
   If the answer was NO or there was no answer, they were reassigned.

NEW:

Auto-checkout.
If the exponents are still being worked on, they are left alone.
If NOT, they are reassigned, without human intervention.

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

Seems to me that the only thing that has changed is efficiency, in no 
longer needing to make extraordinary demands on George's time, nor is it 
subjective any longer, "as time permits" on George's part.

What's the huhu?  You didn't mind that before, so why now?

>And my trust in PrimeNet would be taken away should those partici-
>pants win out who have decided it is "for the good of the group"
>that no one have more than 60 days of work queued up.  Again, I
>will simply choose to not participate if whatever I am working on
>might be reassigned to someone able to finish it faster.

Sorry to lose your efforts, then.   Have you considered using machines that 
slow for factoring purposes?
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

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

Date: Mon, 7 Feb 2000 16:06:20 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: SMP GIMPSing And Sharing The Burden

On 6 Feb 00, at 18:57, Mikus Grinbergs wrote:

> I seem to recall reading a long long time ago that the positioning
> of variables in real memory was being controlled, to ensure that
> certain cache lines were only being used to hold long-persistence
> variables.  (In other words, by placing all short-duration data in
> memory locations that map to OTHER cache lines, the cache lines
> used for long-persistence data would not have to be re-loaded as
> often.)
> 
> If this is true, I'm wondering how newer CPU chips affect such a
> scheme.  In particular, the Athlon has 64-byte wide cache lines,
> whereas the Pentium had only 32-byte wide cache lines.

Since the page size is 4KB and we're talking about 32 or 64 byte 
boundaries, the offset within the page is the same whether we are 
considering physical or virtual memory.

Prime95 is known not to be optimized for the Athlon architecture. 
However it does seem to run reasonably well.

Actually the cache line issue shouldn't be too important. With luck 
you will have pre-loaded some data you're going to need earlier than 
you would have done with 32-byte cache lines; in the worst case 
you'll simply be ignoring half of the cache line content.

Since the page size is 4KB and we're talking about 32 or 64 byte 
boundaries, the offset within the page is the same whether we are 
considering physical or virtual memory. In any case, an application 
cannot directly control its location in physical memory under any of 
the operating systems using a virtual memory scheme.

The optimization that should probably be done for Athlon is to 
organize the code to allow FMUL & FADD to execute in parallel (which 
the Pentium II/III core just can't manage). This could give a speedup 
of the order of 40%.


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

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

Date: Mon, 7 Feb 2000 10:18:37 -0700
From: "Alan Vidmar" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Prime95 causes screen jitters

Hi Russel,

Assuming its not AGP, see if moving the graphics card to a 
different slot further away from the CPU helps.

Also, try moving the monitor away from the CPU.  Does it get 
better?  If possible try a different monitor cable with better 
shielding.

Hope this helps,
Alan


On 6 Feb 00, at 18:57, Russel Brooks wrote:

Date sent:              Sun, 6 Feb 2000 18:57:10 -0800
From:                   Russel Brooks <[EMAIL PROTECTED]>
To:                     [EMAIL PROTECTED]
Subject:                Mersenne: Prime95 causes screen jitters

> I've got my friend's 450MHz PII Aptiva with 256Meg ram running Prime95
> under Win98.  I'm seeing minor interference on the display when Prime is
> running.  If I stop Prime the interference stops.  Not much else is
> running 99% of the time so it's an ideal GIMPS machine but I'm bothered
> by the affect it has on the display.  I've tried all kinds of different
> resolutions and sync rates but the ONLY thing that seems to affect it is
> whether or not Prime95 is running.
> 
> Any ideas? ...suggestions?
> 
> Cheers... Russ
> 
> _________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
> Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers


"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: Mon, 7 Feb 2000 10:26:02 -0700
From: "Alan Vidmar" <[EMAIL PROTECTED]>
Subject: Mersenne: Request for feature

Scott,

Would it be possible to add a CPU type/speed column to the 
"Exponents Assigned" list of the "Individual Account Report"?

This info seems to be collected as the "Machines Assigned to 
PrimeNet" suggests.

Thanks,
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: Mon, 7 Feb 2000 14:47:44 -0500
From: [EMAIL PROTECTED]
Subject: Re: Mersenne: SMP GIMPSing And Sharing The Burden

>Parallel FFTs typically have three steps: 1) crunch like mad on local
>data, 2) global scatter-gather (everybody trades data with everybody
>else), 3) crunch like mad on local data. In the GIMPS case, you want
>an inverse FFT too, so that the order is 12321. With the real FFTs that
>Prime95 uses it's worse...step 3 has some global communication too.
>The communicaton is much more a problem for systems with distributed
>memory, but since speed is of the essence here the communication means
>cache thrashing. Running two processors in parallel will speed things up,
>but I would think that the speedup wouldn't be as great as running two
>copies of Prime95. You could probably get some cool single machine
>statistics though :)

Wouldn't this help tremendously the problem of having to do enormous 10-million
digit primes?

I'm guessing, a client hasn't been attempted, but I'd certainly love to have
one.  I have
way too many machines that are Dual and Quad Processor Intels that could
seriously take
advantage of this.








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

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

Date: Mon, 7 Feb 2000 19:18:23 -0000
From: "Stevw Wateridge" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: The return of poaching?

Vincent J. Mooney Jr.  Wrote:
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: 04 February 2000 22:48
Subject: Re: Mersenne: The return of poaching?


>A good sensible posting.  I concur and thank Jeff Woods for writing it.




But did you have to repeat his whole message to tell us?


Steve

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

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

Date: Mon, 7 Feb 2000 15:06:27 -0600 
From: Jeremy Blosser <[EMAIL PROTECTED]>
Subject: RE: Mersenne: SMP GIMPSing And Sharing The Burden

>>Parallel FFTs typically have three steps: 1) crunch like mad on local
>>data, 2) global scatter-gather (everybody trades data with everybody
>>else), 3) crunch like mad on local data. In the GIMPS case, you want
>>an inverse FFT too, so that the order is 12321. With the real FFTs that
>>Prime95 uses it's worse...step 3 has some global communication too.
>>The communicaton is much more a problem for systems with distributed
>>memory, but since speed is of the essence here the communication means
>>cache thrashing. Running two processors in parallel will speed things up,
>>but I would think that the speedup wouldn't be as great as running two
>>copies of Prime95. You could probably get some cool single machine
>>statistics though :)
>
>Wouldn't this help tremendously the problem of having to do enormous
>10-million digit primes?
>
>I'm guessing, a client hasn't been attempted, but I'd certainly love to
have
>one.  I have way too many machines that are Dual and Quad Processor Intels
that
>could seriously take advantage of this.

Well, I'd say that the main problem with try to parallelize the FFT process
is that it ain't so easy to do, and isn't really worth it in the long run
(i.e. Run 2 copies of Prime95).

a) 99.9% of the math in Prime95 is done using assembly. And multi-threading
w/ assembly isn't exactly easy.
b) Depending on the FFT size, there a several optimizations that could be
used. (Such as radix-4 or radix-8 FFTs)
c) The cost of inter-process communications outweights any performance
gains.

A while back, I thought up a non-FFT algorithm that would be worst case O(N
log N), but I need to work on it a little more to make sure I'm not crazy...
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

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

Date: Mon, 7 Feb 2000 22:40:10 +0100 (MET)
From: Wojciech Florek <[EMAIL PROTECTED]>
Subject: Mersenne: Hypothesis

Hi all!
Due to some reasons I've considered numbers in a form
3*2^n (3,6,12,....)
and I've found that almost in each interval 3*2^n..3*2^(n+1)
there are one, two or three exponents of Mersenne prime.
The first two: 2,3 are below or equal 3*2^0.
`Almost' means that there is a true gap for n=6:
 there are no exponents between 3*64=192 and 3*128=384.
The other possible gap is for n=20 3*2^20=3145728..6291456,
but this is a reminder of the v17 bug (???).
If this hypothesis holds then there should be a mersenne prime
with an exponent between 12582912 and 25165824 and, in the next
range, i.e. up to 50331648. I can not say whether it is 
above or below 32M (10M-digit prime).
Among 36 considered exponents (without 2,3) 25 can be written
as 3*2^n+p OR (sometmes AND) 3*2^n-p, where p is a prime. 
On the other hand,
11 exponents are expressed as 3*2^n +/- c, where c is a composite
number. I've considered only differences with  interval
limits. The smallest is 2203=3*512+(5*149)=3*1024-(11*79).
The others are: 2281,11213,44497,86243,110503,132049,216091,
756839,859433,1257787,2976221. Note that the two largest known
exponents are
3021377=3*2^20-124351 [prime!]  6972593=3*2^21+681137 [prime!]
Any comments?
Regards
Wojtek (WsF)

 

Wojciech Florek 
Adam Mickiewicz University, Institute of Physics
ul. Umultowska 85, 61-614 Poznan, Poland

phone: (++48-61) 8273033 fax: (++48-61) 8257758
email: [EMAIL PROTECTED] 
www:   http://spin.amu.edu.pl/~florek


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

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

Date: Mon, 7 Feb 2000 17:15:32 -0800
From: "John R Pierce" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: SMP GIMPSing And Sharing The Burden

> I'm guessing, a client hasn't been attempted, but I'd certainly love to ha
ve
> one.  I have
> way too many machines that are Dual and Quad Processor Intels that could
> seriously take
> advantage of this.

The current generation of multiple single processors each with their own cac
he sharing a main memory bus is really not suitable, interprocess communicat
ions is just far too slow.

the only kind of parallel processor that really helps at all on large FFT's
are the socalled SIMD vector machines, which are really a single processor t
hat has a bunch of parallel arithmetic units that all work in parallel on th
e same instruction with different data.

The new Intel 'Itanium' aka IA-64 aka merced will undoubtably prove interest
ing for this sort of application, as its a VLIW type architecture which is a
variation on SIMD (you could call it MIMD, multiple instructions on multiple
data).

- -jrp


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

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

Date: Mon, 7 Feb 2000 23:25:22 -0500
From: "Conor McCutcheon" <[EMAIL PROTECTED]>
Subject: Mersenne: AMD Athlon problems

I have a new athlon 750 running either prime95 or mprime 24 hours a day, but
I am getting a ridiculously slow per iteration time for a 9.5 million range
exponent (1.192
sec avg).  I have installed on prime95 on over 20 machines now, including an
Athlon 550 (it gets about .2 something seconds on a 9.4 million range
exponent), and experience tells me this is ridiculous.  CPU failure can be
ruled out, linux dmesg agrees with the bios and box it came in anyway.  Does
anyone have any thoughts on why it is running so slowly?  I looked at the
list archives for someone mentioning such an incident, but did not find
anything that helped.
Thank you in advance for your help.
- -Conor McCutcheon

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

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

Date: Tue, 8 Feb 2000 09:55:38 +0100 (CET)
From: Henrik Olsen <[EMAIL PROTECTED]>
Subject: Re: Mersenne: AMD Athlon problems

On Mon, 7 Feb 2000, Conor McCutcheon wrote:
> I have a new athlon 750 running either prime95 or mprime 24 hours a day, but
> I am getting a ridiculously slow per iteration time for a 9.5 million range
> exponent (1.192
> sec avg).  I have installed on prime95 on over 20 machines now, including an
Is this measured, or the number reported on the screen?

> Athlon 550 (it gets about .2 something seconds on a 9.4 million range
> exponent), and experience tells me this is ridiculous.  CPU failure can be
> ruled out, linux dmesg agrees with the bios and box it came in anyway.  Does
> anyone have any thoughts on why it is running so slowly?  I looked at the
> list archives for someone mentioning such an incident, but did not find
> anything that helped.
> Thank you in advance for your help.
Note that the time taken is dependent on a correctly set CPUSpeed since
the code don't time anything, but counts clock cycles and converts using
the value you gave.

Your low speed reported is consistent with a mistype of 75 for the speed
instead of 750.

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

- -- 
Henrik Olsen,  Dawn Solutions I/S       URL=http://www.iaeste.dk/~henrik/
  Flinx:  Everybody wants to kidnap me.
  Oh well, I'll travel the galaxy and have boring adventures.
  (Pip the Flying Snake spits at something and kills it.)
              The Flinx of the Commonwealth Series, Book-A-Minute version


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

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

Date: Tue, 8 Feb 2000 17:11:15 +0100 
From: "Grieken, Paul van" <[EMAIL PROTECTED]>
Subject: Mersenne: Strange result line inprime V19.2

Some days ago prime V19.2 finished an exponent, the line looks like

UID: grieken/C8B74DDA1, M7563337 is not prime. Res64: CBE45D3443C7D394. WV1:
9BE40783,5609919,80000000

I have two questions:
1.      what is the number behind my UID, never seen in other lines
2.      What means the last number, the one that begins with an 8.
thanks for any reaction

Paul van Grieken
Alcatel telecom Nederland
Afd: TTAC Netwerk Elementen
Tel: 070-3079353
email: [EMAIL PROTECTED]

marklin collector

_________________________________________________________________
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 #689
******************************

Reply via email to