Mersenne Digest Monday, April 19 1999 Volume 01 : Number 547
----------------------------------------------------------------------
Date: Sat, 17 Apr 1999 10:07:32 -0600
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: factor
>> Why factors prime95 only up to 59 bit at exponnent which are for
>> doublechecking?
>>
>> The other (9million) are up to 62 bit.
>>
>> Why is that so?
> Because the large the number, the more factoring is worth doing before
> changing over to the computationally expensive LL test.
I had wondered if it wouldn't be worthwhile to run additional factoring
tests on the smaller exponents, taking them up to 62bit (or more) factoring,
see if we can't find any factors of those numbers that are sitting between
~59bit and ~62bit...just for fun.
Aaron
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sat, 17 Apr 1999 21:52:19 EDT
From: "Foghorn Leghorn" <[EMAIL PROTECTED]>
Subject: Mersenne: Idea for running Prime95
When I first got Windows 95 almost four years ago, I discovered by
accident that command.com, the DOS command processor, can be used as
the Windows GUI shell. When I remembered this recently, I realized
that it could be useful for some people running Prime95 on machines
that otherwise go unattended and do nothing else.
In the file \windows\system.ini, go to the [Boot] section and change
shell=Explorer.exe
to read
shell=command.com /c c:\prime\prime95.exe
substituting the appropriate path for Prime95. The next time the
system is restarted, command.com will launch Prime95 and quit, and
then Prime95 will be the only non-idle task running. In this setup,
not even Explorer or the command processor will be taking up CPU
time. The disadvantage is that the only way to interact with the
system is to type Ctrl-Alt-Del, which brings up the task list and
gives you the option to shut down the system.
This method eliminates the slim share of CPU time being consumed by
the usual GUI shell and other Windows processes. For a system that
must frequently be used for other work, it is not useful. But for
systems that sit unattended for days at a time doing absolutely
nothing but Prime95 (or some other computational program), this
method lets you squeeze out a little extra performance.
Any comments? Does anyone else have experience doing this?
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sun, 18 Apr 1999 01:33:23 +0200
From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
Subject: Mersenne: Re: Mersenne Digest V1 #546
On Thu, 15 Apr 1999 at 09:17:38 -0700, Scott Kurowski wrote:
>I've been working with developers of several client ports.
>
>Chris Smith is about 90% done with a PrimeNet client for UNIX and
>Alphas based on MacLucasUNIX. We'll probably start testing with the
>live server in early May. Until then, the manual testing page is
>about it.
Wouldn't writing a portable library be an idea? The interface
would probably be relatively simple, and code reuse is always good.
My guess is that the routines for Linux (which I can't get to compile
anyway, because of a missing file...) could be reused with little or
no modifications.
- --- snip ---
>hey all. i am very excited about finding a new math discovery.
Me too -- it's by birthday today ;-) (Just had to mention it...)
- --- snip --- (aren't we people replying to digests irritating?)
>He has it running on his Ultra Sparc but, as expected, it is only running in
>32 bit.
I'm sorry that I don't know about UltraSPARCs (but I would give my left hand
for one), but why is this the case?
>plus since
>it's Java, you could run it on your Windows CE device, or anything else with
>a Java engine.
Running Prime95 on a Windows CE machine -- isn't that a bit optimistic at the
moment? I mean, even my (erm, it's not mine) trusty old P60 has problems now
(earlier I used to get some smaller exponents from George, but now I guess
such small ones are only available for double checking). A Windows CE version
would drain battery and just be overly slow. (I really hope it was meant as
a joke ;-) )
>Is there a demand out there for a Java port? It wouldn't be as fast as C or
>ASM for most platforms, but for platforms with NO port at all
Like consoles? ;-) (OK, they don't run Java.)
But I think this might be interesting, not only for non-ported-to platforms.
I think we just discussed this, but it would be nice (for newcomers) to load
a page (any page -- this applet could be spread on thousands of users' pages)
with a factoring applet on, and get the message `Thank you for contributing
some CPU time to GIMPS. Click here to find out more.'.
- --- snip ---
>You may be surprised at just how fast a Java implementation could be.
Yes, especially with JIT compilers. (Wasn't Java really made to be quite fast?
I can still remember when I had just received the JDK, and used it for
almost everything... Because it beat VB (4.0) hands down, at least when it
came to speed.)
>He's doing some work on it to optimize it now and promises to have it
>multithreading in no time. Hmm. His initial timings were based on the
>Ultra Sparc running MacLucasUNIX. For example, M(3217) was only 17% slower
>with Java than with the C code.
Multithreading?
Key rule: For a system with only one CPU, multithreading will not make it
faster. But who knows, those monsters may have 256 of them, for all I know.
At least they're expensive enough.
- --- snip ---
>> think there are enough Linux users out there
>> to justify it.
>here's mine:
>
>xterm -display localhost:0.0 -name mprime -e tail -f results.txt &
That's the closest thing you get, I agree. We do not need a GUI for Linux
in any way. mprime has already got an excellent (text-mode) menu, and runs
in the background virtually all the time anyway.
/* Steinar */
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sun, 18 Apr 1999 11:16:08 +0100
From: Gordon Spence <[EMAIL PROTECTED]>
Subject: Mersenne: Re: Compiler Optimisations
>Date: Thu, 15 Apr 1999 16:08:56 +0200
>From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
>Subject: Mersenne: Re: preventive measures
>
[snip]
>
>You have an entirely wrong picture of what assembly is. Assembly is the
>most high level programming language existing. It is _not_ a portable
language
>like C, where the C compiler actually _converts_ (compiles) the C code into
>assembly code for the machine that is to run the program, optimizes it
>and finally runs it through an assembler and linker to create the full
program.
>
Are you sure about this? maybe you meant to write - Assembly is in fact
the *lowest* possible level of programming. You are quite correct though
about it being non-portable. It is processor specific.
And that is precisely why it *is* possible to have a compiler do the following
1. produce code that has processor specific opcodes
2. produce code that is optimised for different processor architectures
- both in terms of execution & pipelining units, taking advantage of out
of order & speculative execution etc.
3. produce code that can approach the best hand-tuned assembly code
>In other words, the phrase `recompiling the assembly in a compiler that is
>PIII/K63 aware' is totally meaningless. There will soon be PIII aware
>assemblers (for some reason, I belive gas will be one of the first... How
>strange.), but all they will do is enable the user to use the new opcodes (as
>well as the more `standard' opcodes, some of which have been around since the
>8086 (good old days... I had an 8088)).
Hold on a minute you contradict yourself here, now is it possible or isn't it?
>Regardless of which assembler you use,
>the code will stay at the exact same speed, as opposed to C compilers, where
>it in fact can make a big difference.
Perhaps someone who has access to multiple compilers can prove or disprove
this. I know many years ago that the Watcom compilers always used to come
out pretty good. Mu gut instinct tells me that this is probably still the
case.
Gordon Spence, Nokia IP Telephony
Applications Engineer Grove House, Waltham Way,
[EMAIL PROTECTED] White Waltham, Maidenhead,
http://www.nokiaiptel.com/ Berkshire, SL6 3TN, UK.
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sun, 18 Apr 1999 11:10:12 -0000
From: [EMAIL PROTECTED]
Subject: Re: Mersenne: factor
>>> Why factors prime95 only up to 59 bit at exponnent which are for
>>> doublechecking?
>>>
>>> The other (9million) are up to 62 bit.
>>>
>>> Why is that so?
>
>> Because the large the number, the more factoring is worth doing before
>> changing over to the computationally expensive LL test.
Let the number to be tested be 2^n-1, p(k) be the probability of discovering a
factor by trial-factoring to k bits, t(k) be the time taken to trial-factor to k
bits and T be the time taken to run a LL test.
If what we want to do is to determine the primality or otherwise of 2^n-1, what we
want to do is minimise t(k) + (1-p(k))*T(k) ; if we find a factor, there is
clearly no point in running a LL test.
Now, in broad terms and ignoring irregularities caused by hardware:-
(a) t(k) is proportional to 2^k : there are as many candidate factors between
2^k+1 and 2^(k+1) as there are between 1 and 2^k;
[Actually there are distinct "steps" in this relationship at k=62, k=63 & k=64
caused by the number of significant bits to which the result of a floating-point
operation is accurate]
(b) t(k) is proportional to 1/n : since all the candidate factors are of the form
2an+1 for some integer a, there are *less* candidates for larger values of n;
(c) p(k) is proportional to some increasing function of k - possibly approximately
logarithmic, but clearly less than linear;
(d) T(k) is proportional to n^2.
[Actually the Prime95 implementation proceeds linearly between steps caused by
jumps in the FFT transform size. Theoretically there would be a linear
relationship between the iteration time and the FFT transform size; but the FFT
transform sizes are not equally efficient, exact powers of 2 are inherently more
efficient than intermediate sizes; and the proportion of L2 cache misses tends to
increase with the FFT transform size]
Putting all this together and stirring in a bit of empirical evidence, it has been
found that the best balance is found when t(k)/T(k) is a bit less than 0.1.
>I had wondered if it wouldn't be worthwhile to run additional factoring
>tests on the smaller exponents, taking them up to 62bit (or more) factoring,
>see if we can't find any factors of those numbers that are sitting between
>~59bit and ~62bit...just for fun.
Just for fun, why not? But it will probably take longer to add 4 bits to the
factoring depth of any particular exponent (15 times as much time as has already
been spent trial-factoring) as it would to run the LL test again. You will also
need a copy of Prime95 which has been "doctored" to allow factoring to a greater
than normal depth. And, though you will certainly find *some* factors, there will
be a large proportion of negative outcomes.
Also, as the size of the factors increases, probabilistic methods of finding
factors (ECM, P-1) become relatively much more efficient than exhaustive
elimination of factors. At what point they become "cost effective", I'm not sure;
but it's certainly unrealistic to suppose that, e.g., M727 would ever be factored
by trial division, whereas other methods will almost certainly succeed some time
in the next few years.
Regards
Brian Beesley
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sun, 18 Apr 1999 17:40:58 +0200
From: "Jean-Charles Meyrignac" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: Compiler Optimisations
>
>And that is precisely why it *is* possible to have a compiler do the
following
>
>1. produce code that has processor specific opcodes
>2. produce code that is optimised for different processor architectures
> - both in terms of execution & pipelining units, taking advantage of out
>of order & speculative execution etc.
>3. produce code that can approach the best hand-tuned assembly code
>
I recntly worked onto manually pairing my assembly code, but the timings
were always different on the same processor !
I think this re-pairing can be done efficiently by program.
So, I've recently imagined a source optimiser, something more powerful than
Vtune.
It would take an assembly source and create another source which is
fine-tuned for any 386 processor.
Has it been already done ?
I know it already exists for C and Fortran...
>
>>Regardless of which assembler you use,
>>the code will stay at the exact same speed, as opposed to C compilers,
where
>>it in fact can make a big difference.
>
>Perhaps someone who has access to multiple compilers can prove or disprove
>this. I know many years ago that the Watcom compilers always used to come
>out pretty good. Mu gut instinct tells me that this is probably still the
>case.
>
I have access to a lot of compilers, but the best for Windows at this moment
seems to be Microsoft Visual C++ 6.0.
The latest version includes dead code elimination (thus reducing the final
EXE file, for example, recompiling Prime95 saves around 30 kilobytes of
executable).
And above all, this compiler included all optimisations suggested by Agner
Fog (although floating point generation is still weak).
You can check them at http://agner.org/assem/
Jean-Charles
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Sun, 18 Apr 1999 17:17:19 -0400 (EDT)
From: lrwiman <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Idea for running prim95
All,
yes, you can set the shell to command.com or prime95, or
whatever. There is another way to interact with the
system, you can do this by pressing Ctrl+Esc to bring
up the tasks menu. From there, you can run any program
that you want to. This seems like it might increase
the system resources available to prime95. You could
combine this with:
safe mode,
a boot menu which can load up an autoexec.bat that
would make this automated:
eg:
:prime95
del c:\prime95\system.tmp
copy c:\windows\system.ini c:\prime95\system.tmp
del c:\windows\system.ini
copy c:\prime95\system.ini c:\windows\system.ini
you could even do something similar with the registry,
to reduce overhead.
- -Lucas
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Mon, 19 Apr 1999 15:41:18 +0100
From: Chris Street <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Idea for running Prime95
This does work well - and I used to run a similar system for some reason
under Windows 3.1 - but I cannot remember why. The overhead from the GUI
and so forth can be considerable - try turning on the performance
monitor and moving the mouse rapidly. This can eat up 10-15% of the cpu
time just recalcing anf then redrawing the mouse pointer - it gets worse
if you haev one of the fancy animated cursors loaded. For a system that
will do nothing else it cannot hurt and may even make the system more
stable.
> -----Original Message-----
> From: Foghorn Leghorn [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, April 18, 1999 2:52 AM
> To: [EMAIL PROTECTED]
> Subject: Mersenne: Idea for running Prime95
>
>
> This method eliminates the slim share of CPU time being consumed by
> the usual GUI shell and other Windows processes. For a system that
> must frequently be used for other work, it is not useful. But for
> systems that sit unattended for days at a time doing absolutely
> nothing but Prime95 (or some other computational program), this
> method lets you squeeze out a little extra performance.
>
> Any comments? Does anyone else have experience doing this?
>
> _______________________________________________________________
> Get Free Email and Do More On The Web. Visit http://www.msn.com
> ________________________________________________________________
> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
Date: Mon, 19 Apr 1999 21:51:42 -0400 (EDT)
From: lrwiman <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Idea for running Prime95
>> yes, you can set the shell to command.com or prime95, or
>> whatever. There is another way to interact with the
>> system, you can do this by pressing Ctrl+Esc to bring
>> up the tasks menu. From there, you can run any program
>> that you want to. This seems like it might increase
>> the system resources available to prime95.
>How? Why?
When I said "This seems..." I was referring to his idea in general,
sorry for the confusion
>Ctrl+Esc is just a "shortcut" to the "Windows" key
This is not true, when you bring up windows with the shell
explorer loaded, then it is a hotkey for the start bar.
When there is another shell loaded, Ctrl+Esc is a hotkey for
the "tasks" window. With this window, you can run any file using
file-run. I *have* actually tried this both at the computers at school,
as well as when I ran shell=command.com (independently of Mr. Leghorn.)
>I must say that, if anything, popping up the "Start" menu to
>run a program ought to cost _more_ system resources than
>simply starting it by double-clicking a desktop shortcut.
You are correct that bringing up the start menu is more of a drain on
resources. This doesn't actually have any (or at least very little)
affect on the performance of program, as both of these tasks have terminated
by the time the program has completed loading.
Cheers,
Lucas
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
------------------------------
End of Mersenne Digest V1 #547
******************************
