Another new prime (M42-Related)

[jinydu]

Its amazing how many replies to this have already appeared on Slashdot;

http://science.slashdot.org/article....tid=146&tid=14

But admittedly, most of the users there are totally ignorant about primes...

[edorajh]

If it turns out that it is really Mersenne Prime congratulations to discoverer and all GIMPSters. Keep up the great search!


Edo

[Prime95]

I just checked my logfiles and found another email address for this user. Maybe I was using the wrong one...

[T.Rex]

I've just launched GLucas on a 16xia64 Bull NovaScale machine for verifying M42.
I've no data yet. So I have no idea of the time needed for the verification.
I'll let you know when the result is expected.

Tony

[T.Rex]

The check should take 5 days and a half (if everything's OK ...) starting now. So the result should be known Saturday morning USA time. Or Sunday morning if if finishes late Saturday night.
With a 32xia64 machine with 1.5 GHz processors, that would had taken ~ 2 days ...

Tony

[Mystwalker]

So it is possible to speed up testing with multiple CPUs (at least using GLucas)?

[Orgasmic Troll]

How does one get on the mailing list?

[jinydu]

Originally Posted by TravisT

How does one get on the mailing list?

http://hogranch.com/mailman/listinfo/prime

But beware, you get many emails that you're probably not interested in.

Also, Weisstein seems to be getting confident:

http://mathworld.wolfram.com/42.html

[T.Rex]

Originally Posted by Mystwalker

So it is possible to speed up testing with multiple CPUs (at least using GLucas)?

I've been able to experiment on a 32xia64 machine. Very interesting. 32 threads on a 32x machine runs as fast as 16 threads on a 16x machine ... Not faster. Disapointing, isn't it ?!
It is a NUMA machine, so the time for accessing data is not the same for all threads. Also, the memory is allocated around the memory region where GLucas started, probably by the first thread. Maybe the memory bus is saturated. Using a NUMA command asking the system to allocate the memory on all blocks leads to better performances. If each thread could allocate the memory it needs, that would probably improve locality and help the system to put together the threads and the memory they use. But I guess parts of these chunks of memory are used by several threads. Maybe also there is a contention.
On other kinds of large machines (like IBM PowerPC SMP machines), the NUMA factor is lower, I think, and scalability is better. But these machines are more expensive.
About GLucas, I plan to experiment with our Thread Trace Tool in order to SEE what's happening inside GLucas. That will be a great example for my project, aimed to provide help for analyzing the dynamicity of multi-threaded applications. Guillermo Ballester Valor (the author of GLucas) spent a lot of time building symetric threads. Maybe there is something that disturbs the symetry.

Tony

[Jeff Gilchrist]

Originally Posted by Mystwalker

So it is possible to speed up testing with multiple CPUs (at least using GLucas)?

Yes, up to a certain point (as Tony mentioned).

Prime95 is highly optimized for the x86 architecture. A 3GHz P4 does about 0.05 sec/iteration with Prime95 but can only use one CPU for an LL test.

Running Glucas (a generic C program) on a 1.2GHz Alpha machine is much slower using 1 CPU (but can run on multiple CPUs). Using 8 CPUs is about the same speed as the P4 listed above. Using 10 CPUs is faster at 0.04 sec/iteration.

The Itanium is even faster per clock than the Alpha is running Glucas.

Jeff.

[leifbk]

Originally Posted by Jeff Gilchrist

Running Glucas (a generic C program) on a 1.2GHz Alpha machine is much slower using 1 CPU (but can run on multiple CPUs). Using 8 CPUs is about the same speed as the P4 listed above. Using 10 CPUs is faster at 0.04 sec/iteration.

If I have understood it correctly, the optimization is mainly dependent of how you compile the program on a multi-CPU architectures. If you try to run the binary from the 1 CPU machine on the one with 8 CPUs, you won't see any improvement at all, as it must be recompiled for each configuration.

Super-computers and their compilers have a really fascinating symbiosis. The compiler has a role very similar to the director of a symphony orchestra, as every single member must play its small part exactly at the right moment to create the whole.

regards, Leif.