Mersenne Digest        Thursday, April 22 1999        Volume 01 : Number 548




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

Date: Tue, 20 Apr 1999 10:21:19 -0500
From: "Griffith, Shaun" <[EMAIL PROTECTED]>
Subject: Mersenne: Java Ports?

Some of the new bench equipment coming out (scopes, analyzers, etc.) now run
Java too. Many are connected to the network (for data transfer and PC
control). Utilization is about 10%. Hmmmm.

And I can't wait until I get my net-aware refrigerator running LL tests ;)

But what I really want is for someone to get those telemarketing computers
to decide that LL testing has a higher priority than calling me during the
Dilbert show.

Shaun Griffith 
Quantum Mechanics: The dreams stuff is made of
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Tue, 20 Apr 1999 13:05:54 -0600
From: "Blosser, Jeremy" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Re: Mersenne Digest V1 #546

>-----Original Message-----
>From: Steinar H. Gunderson [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, April 17, 1999 6:33 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Mersenne: Re: Mersenne Digest V1 #546
>
>
>
>>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?
>

Well, my assumption is that GCC doesn't do 64-bit... I wish I were a Ultra
guru like the one that did the DES port for Distributed.net... that thing
flies! I was getting > 24Million keys/sec on just that one Quad machine...
The Quad Xeons were only getting 16 Million... :P

Plus, I'm not sure if the code is optimized for 64-bit...

>>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 ;-) )
>

Actually, surprisingly, the CE devices should do pretty well... (Just keep
'em charged!)
For example, the Jornada 820 we have here at the office has a 190Mhz
StrongArm SH3 processor in it...
See Benchmarks Below...

The only concern I have is memory on the CE devices...

>>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

Comparisons for you:
- ---Sun UltraSparc (not sure what speed, 240?)
P=19937
- --MacLucasUNIX
15.929sec = .0007s/iteration
- --JavaLucas (JDK 1.2)
128.348sec = .006s/iteration

- ---Intel P2-412
P=19937
- --Lucas
50.11sec = .0025s/iteration
- --JavaLucas (Jview)
52.797sec = .0026s/iteration
- --Prime95
.037s/iteration (Of course, the FFT is huge so its not a fair comparison :P)

- ---RS6000
P=19937
- --JavaLucas (Bleh, this is slow... something went wrong here... no JIT?)
61.158sec  = .003s/iteration


I'd try it on that AS/400, but I hate the damn thing... (Its got 4 PPC
604e's in it tho)

So... there is an order of magnitude difference between MacLucasUNIX and
JavaLucas, but not between Lucas and JavaLucas... So I guess I shoulda
ported from MacLucasUNIX (I just wanted to do a sanity check for myself
first)...

Actually, looking at the JavaLucas vs Prime95 for a big P (6466417), I'm
getting 3.3s/iteration vs. .02s/iteration... So 2 orders of magnitude... 
I think that sounds right...

>
>Like consoles? ;-) (OK, they don't run Java.)
>

Actually, the Sega Dreamcast will run on WinCE, so I assume Java support
will be there...
Also, I think it is ummm... Sony or someone will have a console running
JavaOS... (WACKY aint it?)
Plus, think about all the phones, toasters, microwaves and doorstops coming
out that 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.

Actually, it was on my P2-300 against Lucas.c, and I've caught up with
that... On to MacLucas... :)

>
>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.
>

Duh... of course threading on one CPU won't make it faster, slower is more
likely...

But when you have a lot of SMP machines sitting around, its more fun to run
just one proggy rather than 4 or 12 or 24 ;)

I'd like to see if I can get the FFT code to multithread tho. That'd be
cool... Test single prime faster at least, but I don't know if there are any
parallel FFT algorithms... Pointers anyone?

******
Actually, I don't really know anything about FFTs, so any help would be
appreciated... I have come to realize that I need to brush up a bit on my
math... Its been too long since college...
******

Plus, you could coordinate a buncha Java clients running around and stuff
pretty easily...

Anyway, there's work to be done, but I thought I'd post some figures that I
have to date...
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Tue, 20 Apr 1999 17:59:23 -0600
From: "Blosser, Jeremy" <[EMAIL PROTECTED]>
Subject: Mersenne: JavaLucas... Cool...

For lotsa fun, I ran:

JavaLucas P = 521 on a HP 620LX (Handheld PC, 75Mhz SH3, 16MB Ram,
WinCE2.0sp1)
Results:
  Total time: 33 sec
  Sec/Iteration: .063 sec

Thoughts:
Its REALLY slow :) (No JIT... I dunno, MS wasn't too helpful here (I wonder
why...) I'm unsure they'll ever have a JIT version... maybe 3rd part support
is forthcoming)
I need to put a GUI on it... had to get the results from the log, and its
hard to tell when it finished. :P
I'm still a little worried about RAM...
Anyone know where to get an updated JVM for WinCE? I can't find it on
Microsloth's site...

ToDo:
Convert to MacLucasUNIX routines
Add GUI
Add checkpoints
Run on HP820 (WinCE)
Run on JavaStation
Run on IBM NetStation
Run on AS/400
Add PrimeNet support
Multithreading (?)
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Tue, 20 Apr 1999 21:02:12 -0400
From: "Paul Missman" <[EMAIL PROTECTED]>
Subject: Mersenne: FreeBSD compatibility

Hello,

I wrote the FAQ instructions for running mprime under FreeBSD, which
you will find on the Primenet server.  Unfortunately, with the 3.0 releases
and later of FreeBSD, these instructions are not working any longer.

Is there anyone on the list that is running FreeBSD 3.0 or later with
mprime,
who could amend the directions?  I've had a couple folks asking me for
help, but I don't have a 3.0 or later version, and am not likely to get one.

I hate to have folks not running mprime, just because FreeBSD changed
its ELF handling.

Thanks,

Paul Missman


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

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

Date: Tue, 20 Apr 1999 23:09:30 -0400
From: Bryan Fullerton <[EMAIL PROTECTED]>
Subject: Re: Mersenne: FreeBSD compatibility

On Tue, Apr 20, 1999 at 09:02:12PM -0400, Paul Missman <[EMAIL PROTECTED]> wrote:
> 
> Is there anyone on the list that is running FreeBSD 3.0 or later with
> mprime,
> who could amend the directions?  I've had a couple folks asking me for
> help, but I don't have a 3.0 or later version, and am not likely to get one.

I am - two machines doing LL and one doing factoring.

The only problem I have is that mprime doesn't seem to be able to understand
that it's online, and never actually tries to contact the PrimeNet server -
it just keeps saying "You are not connected to the Internet.".  Apparently
this is because mprime looks for /proc/net/route to see if the machine is
on the net, which FreeBSD doesn't have (all three machines I run mprime on
are on dedicated Internet connections).  I run my FreeBSD machines in offline
mode, using the manual PrimeNet web forms to request/report exponents.

There's also the issue of memory usage, which may or may not be a problem
depending on how beefy and/or busy your machine is.  As an example:

  PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
  307 bryanf   105  20 18012K  2812K RUN     37.6H 98.19% 98.19% mprime

It's grabbed 18Mb of memory, though only 2.8Mb is resident.

There is a native FreeBSD client rumoured to be forthcoming which should
resolve these problems, and which I'm really looking forward to.  :)

> I hate to have folks not running mprime, just because FreeBSD changed
> its ELF handling.

I'm unsure what you mean by this - FreeBSD changed to ELF as it's main object
type (with a.out support still included) with the 3.0 release, so it should be
easier to run ELF stuff.  Just enable Linux support in rc.conf, reboot, and
run the binary.  Then when it starts complaining that it's not connected to
the Internet (ack), turn off PrimeNet connections, use the web forms, and cut
and paste into worktodo.ini.

Bryan

- -- 
Bryan Fullerton                http://www.samurai.com/
Owner, Lead Consultant         http://www.feh.net/
Samurai Consulting             http://www.icomm.ca/ 
"No, we don't do seppuku."     Can you feel the Ohmu call?
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

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

Date: Wed, 21 Apr 1999 11:47:17 +0000
From: "Steinar H . Gunderson" <[EMAIL PROTECTED]>
Subject: Mersenne: Re: Mersenne Digest V1 #547

On Mon, Apr 19, 1999 at 06:53:08PM -0700, Mersenne Digest wrote:
>And that is precisely why it *is* possible to have a compiler do the following

Yes, a compiler.

Assembly doesn't use a compiler. A compiler changes the C code into assembly
code. The assembler only translates the assembly codes into opcodes. The only
reason processors read opcodes instead of the ASCII text representing 
assembler code, is because it's faster and takes less space.

In other words, a single line of C code could translate into as many as 20-30
assembly instructions, possibly even more.


>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

Yes, but that is C code. The reason C code is much more popular than assembly,
is (among other things) that it is portable.

>>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?

It is not possible. With a `PIII compatible' or `PIII aware' assembler, I mean
that it can emit the new opcodes. BUT NOT AUTOMATICALLY. The programmer will
still have to use and type in the new instructions, but the assembler will
know which bytes to emit. If you try to insert PIII opcodes in an `old'
assembler, it will simply give you an `unknown instruction' error.

>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.

Again, we are talking C code. Everybody have their favourite C compiler,
whether it be MSVC, Borland, Watcom or GCC. Not assembly. Microsoft's assembler
would emit exactly the same code as Borland's. Read the Intel CPU specs once
and see what your instructions are _really_ converted to. Or use your compiler's
`assembly listing' function once.

- --- snip ---

>Has it been already done ?
>I know it already exists for C and Fortran...

It's much more difficult to improve existing assembler code than generate new,
efficient one. This is because it's often much more difficult to find out
exactly what the assembly code is trying to do. In addition, there may be side
effects that are not really important for the program, but how do you tell an
optimizer that?

An easier idea (I believe) would be a program that can detect stalls in the
assembly code, and leave it to the programmer to eliminate these stalls.

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

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

Date: Wed, 21 Apr 1999 13:25:53 -0600
From: "Blosser, Jeremy" <[EMAIL PROTECTED]>
Subject: Mersenne: JavaLucas (again) Large FFT results and I need some help oh great 
prime gurus...

Hmmm... for some odd reason I didn't post the sec/iteration for a large FFT
(someone pointed this out to me)

So I ran JavaLucas with an FFT of 256k Its getting 1.75 sec/iteration. So...
not too shabby really...

Anyways, on to the questions:

1) What the algorithm for finding the best FFT size. I was doing:
        int n = 1;
        int mm = q/16+1;
        while (n < mm) n  <<= 1;
        n>>=1;
but that is wrong...

So I looked at MacLucasUNIX, and it has:

        while (n < ((BIG_DOUBLE)q)/ROUNDED_HALF_MANTISSA + 4.0)
                n <<= 1;
          size = n + ((n & MASK) >> SHIFT);

What I can't find is where the ROUNDED_HALF_MANTISSA came from, and why the
mask and shift operation?

2) I'm looking at the code, in Lucac.c and it looks like:
        a) create the scrambled array scrambled[j] = n[permute[j-1]] *
two_to_phi[permute[j-1]]
                (not quite sure why)
        b) it converts the scrambled array to fft, squares it, does the
inverse fft...
        c) multiplies the scrambled array * two_to_minusphi
                (Is this the mod here???)
        d) calls addsignal
                (this one has me lost)
        e) calls patch
                (carry?)

So, my question is, where is the subtraction?
        n = (n*n-2) % (2**p-1)

I see the square, I see (I think) the mod... wheres the -2?

3)  I was thinking in the shower this morning... (Odd ain't it?)

And for all n < 2**p-1, the answer will always be n*n-2 right? Also, if n <
sqrt(MAXLONG), then we can do it in place without the FFT...
Just looking at some data sets, the odd of n being less than sqrt(MAXLONG)
is actually not to bad... (especially in Java which has 64-bit longs)...
So where does this short cut fit in? (with a big FFT, this can be a big
difference (I think))...

Thanks for any help
- -Jeremy


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

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

Date: Wed, 21 Apr 1999 15:55:16 -0700
From: "Scott Kurowski" <[EMAIL PROTECTED]>
Subject: Mersenne: Beta version of FreeBSD 3.x native client for PrimeNet

Hi all,

Nick Hilliard has finished the native FreeBSD 3.x version of v18.1
MPrime for PrimeNet.  It is a limited availability beta version we
want to first test on relatively fast machines to see complete test
cycles as soon as possible.  Following a few weeks of testing the
general availability release should be ready, including source code.

If you are interested in testing the new FreeBSD 3.x client, please
email me at <[EMAIL PROTECTED]> before Friday 23 April.

Best regards,
scott

P.S. Paul Missman pointed out MPrime for Linux apparently runs only on
FreeBSD 2.x in the Linux compatibility mode. (thanks Paul)

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

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

Date: Thu, 22 Apr 1999 16:11:11 -0700
From: Gordon Irlam <[EMAIL PROTECTED]>
Subject: Mersenne: SurfWatch tester needed

Hi,

I reported earlier how SurfWatch was blocking access to all my sites.

When I sent out email on this topic, I didn't bother to first
communicate with SurfWatch.

At the time I was annoyed, and had the attitude: they don't have the
courtesy to tell me they have been blocking my sites for the last two
years, so why should I bother communicating with them before complaining
to the net at large about their practices.

Philip Heede of the Mersenne list decided to take up my case with
SurfWatch, and as a result I believe I am now unblocked.

If someone who uses SurfWatch can confirm for me that the following
sites are now accessible:

    www.base.com
    www.surf.base.com
    www.nanodevices.com
    www.apache.net

that would be great.

I will then remove my "Censored by SurfWatch" baner from the top of my
pages.

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

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

End of Mersenne Digest V1 #548
******************************

Reply via email to