How fast does this run on your PC?

[RupertPupkin]

Well, so far it looks like we can conclude:

1. For large integer arithmetic, 64-bit > 32-bit.
2. For large integer arithmetic, AMD > Intel.
3. sideways likes to find ways to cheat. Good man.
4. bee needs faster hamsters in his PC

[bee]

Originally Posted by RupertPupkin

Dude, that's not a foot pump...that's your mouse!

ahahahah
very funny!!! i must think you're right
I could feel like those people that are using a cd try as coffee cup holder but, ok, i will just say that my hamsters are the guilty

bye!!!

[stevea]

A few points worth considering ...

The AMD architecture hsa for some time crushed on mem bandwidth, to that part isn't surprising (i7 may spoil the magic sauce).

Sideways broke the code - this calculation is trivial - can easily and rapidly be done in a shell script EXCEPT the decimal representation.

Sideways result contains a large fraction of disk I/O time, so if you ">/dev/null" or comment out the print altogether (as per Shunk) you'll see a substantial improvement.

So the original test is primarily consumed with dividing a multi-precision by 10 and remainding nearly 13 million times (actually you can pull ~8 digits per divide (or even more for 64bit ints) so perhaps only 1.5 mill divides or less.

OK so the puzzling thing is that if you dbl the number of bits then you be able to extract the decimal representation more tha n2x as fast ... more like 2/ln(2) IIUC. So either the memory bandwidth dominates or the conversion to decimal in libgmp is suboptimal.

[sideways]

Originally Posted by stevea

A few points worth considering ...
Sideways result contains a large fraction of disk I/O time, so if you ">/dev/null" or comment out the print altogether (as per Shunk) you'll see a substantial improvement.

So the original test is primarily consumed with dividing a multi-precision by 10 and remainding nearly 13 million times (actually you can pull ~8 digits per divide so perhaps only 1.5 mill divides.

The disk I/O is negligible, calculate the result in base 2 and you still get a 42Mb file generated in ~ 1 sec.

If you raise 3 to the same power (just replace 2 by 3 everywhere in the source-code) the result is not binary friendly (ie it's not a sequence of repeating characters) but the base 16, 8, 4, 2 etc output is still very fast (though not quite so fast)

Converting to other bases like 11, 13 etc is similar in performance to base 10. So maybe humans should have discounted thumbs and learnt to use base 8, then we'd be more in sync with computers

But clearly 64 bit is much faster for this stuff, at least on pcs, there's an article on the gmp homepage where they look at a counterexample on an ultrasparc and discredit it.

They also claim "GMP is faster than any other bignum library". But how do they know what the Intelligence Services around the world are using? eh

[igla]

Fedora 10 x86_64
Intel Q2Q6600

real 0m26.196s
user 0m26.032s
sys 0m0.108s

[stevea]

Originally Posted by sideways

The disk I/O is negligible, calculate the result in base 2 and you still get a 42Mb file generated in ~ 1 sec.

Wrong ! The disk I/O is a considerable fraction of the hex version time
# time ./mersenne-hex 43112609 > /other/M46
real 0m0.110s
user 0m0.042s
sys 0m0.067s
# time ./mersenne-hex 43112609 > /dev/null
real 0m0.060s
user 0m0.046s
sys 0m0.014s
The big(ger) sys time is a dead give-away.

If you raise 3 to the same power (just replace 2 by 3 everywhere in the source-code) the result is not binary friendly (ie it's not a sequence of repeating characters) but the base 16, 8, 4, 2 etc output is still very fast (though not quite so fast)

Right - agreed, but this is only b/c the Gnu multi-precision package uses a binary representation internally instead of a selectable base (some power of 3 for this example). Actually the ancient and strangely attractive APL interpreted used to be able to delay calculation and leave operations in an internal symbolic representation UNTIL the evaluation of a particular term was required. At that point it would try to optimized the calculation (often that meant just calculating the required portions of a matrix .. but other more complex opeations too).

Anyway that sort of delayed optimization could usefully be applied if we intended to calculate x^y - 1 and represent this in base b a lot.

Converting to other bases like 11, 13 etc is similar in performance to base 10. So maybe humans should have discounted thumbs and learnt to use base 8, then we'd be more in sync with computers

Or perhaps we should only have considered our thumbs and begun with base 2
((Actually that's too few symbols for our arithmetic alphabet, and would make for excessively long strings))

But clearly 64 bit is much faster for this stuff, at least on pcs, there's an article on the gmp homepage where they look at a counterexample on an ultrasparc and discredit it.

They also claim "GMP is faster than any other bignum library". But how do they know what the Intelligence Services around the world are using? eh

GMP has been around for a long time and it is impressive. I've used pari-gp ((a calculator based on gmp)) for a number of years and it's really hand when it's called for. Actually you can perform Rupert's Mersenne calc in one line of pari *BUT* the pari I have is based on a buggy older gmp that has a bug above several million digits.

[Jake]

My Computer is damn slow.. but not slow considering it's age (2005)

[Jake@localhost Desktop]$ time ./mersenne 43112609 > M46

real 0m21.928s
user 0m20.241s
sys 0m0.279s
[Jake@localhost Desktop]$

2.0GHz AMD 64 Single core.

Though my machine is mainly used for compiling and virtual machines..

Also on a re-check:

[Jake@localhost Desktop]$ time ./mersenne 43112609 > M46

real 0m20.909s
user 0m20.207s
sys 0m0.311s
[Jake@localhost Desktop]$

[YeOK]

hmm..

I run this test before here.

I installed 2.6.29-0.6.rc3.fc10.x86_64 kernel from koji and out of pure interest thought I'd run this test again.

time ./mersenne 43112609 > M46

real 0m11.958s
user 0m11.863s
sys 0m0.073s

Anyone else with the updated kernel get a better time?

[RupertPupkin]

Originally Posted by YeOK

I run this test before here.

I installed 2.6.29-0.6.rc3.fc10.x86_64 kernel from koji and out of pure interest thought I'd run this test again.

time ./mersenne 43112609 > M46

real 0m11.958s
user 0m11.863s
sys 0m0.073s

I think your new result is still within the usual amount of deviation when running multiple times. The improvement is only 0.383 seconds. My guess is that a new version of gmp[-devel] would probably have more of an impact than a slightly newer kernel.

[sonoran]

Interesting post!

[pcg@localhost ~]$ time ./mersenne 43112609 > M46

real 0m21.769s
user 0m21.270s
sys 0m0.177s

Hardware:

AMD 64 3000+
Gigabyte GA-K8NSC-939 mobo
2 gig

(circa 2005, but still in the race!)

[pete_1967]

Temp]$ time ./mersenne 43112609 > M46

real 0m14.523s
user 0m14.417s
sys 0m0.091s

Specs in sig

[got_root]

[root@xps Desktop]# time ./mersenne 43112609 > M46

real	0m46.366s
user	0m45.820s
sys	0m0.402s

pretty bad for a Core2Due T7500 @ 2.2GHz with 4GB Ram right?

I took a look at the SystemMonitor and saw that only one core runs at 100% during the test. The other is @ 5% or so.

Is this normal or what?

[skolnick]

Statistics for my PC: (AMD 5600+ with CPU throttling enabled and 2GB RAM, running Fedora 8 32 bits)

[gpulido@hades ~]$ time ./mersenne 43112609 > M46

real    0m30.914s
user    0m29.247s
sys     0m0.367s
[gpulido@hades ~]$ uname -a
Linux hades.localdomain.local 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 19:19:45 EST 2008 i686 athlon i386 GNU/Linux
[gpulido@hades ~]$

I took a look at the SystemMonitor and saw that only one core runs at 100% during the test. The other is @ 5% or so.

Is this normal or what?

i think this is normal, since the program seems to be single-threaded.

Regards.

[messner]

mersenne.c:3:17: error: gmp.h: No such file or directory
mersenne.c: In function ‘main’:
mersenne.c:7: error: ‘mpz_t’ undeclared (first use in this function)
mersenne.c:7: error: (Each undeclared identifier is reported only once
mersenne.c:7: error: for each function it appears in.)
mersenne.c:7: error: expected ‘;’ before ‘M’
mersenne.c:8: error: ‘M’ undeclared (first use in this function)
mersenne.c:8: error: ‘powerof2’ undeclared (first use in this function)
mersenne.c:9: error: ‘one’ undeclared (first use in this function)
mersenne.c:10: error: ‘two’ undeclared (first use in this function)

I get this error while compiling ;(

[bee]

Originally Posted by messner

I get this error while compiling ;(

Well maybe you don't have that gmp-devel package installed!

# yum install gmp-devel

bye!!!!!!