Paul's PRPrime Page - Page 4

J.F. · 2013-05-31, 19:03

Oh hi, Jan (Feitsma) here. It seems this thread was temporary hi-jacked, sorry Paulunderwood... maybe any further such discussions should be moved to Charles' thread called 'Pseudoprimes'?

Yes a paper is now on the agenda, I got persuaded. Followup is planned for later this summer. WraithX and Jeff are contributing too, covering the verification efforts.
As Danaj noted, 64-bit is a rather nice bound mainly because of assembly optimizations.
Henryzz: a ballpark estimate for amount of work spent would be 70 CPU years (by me at least, in 2008, not sure about WraithX/Jeff).

paulunderwood · 2013-05-31, 19:13

Quote:

Originally Posted by J.F.

Oh hi, Jan (Feitsma) here. It seems this thread was temporary hi-jacked, sorry Paulunderwood... maybe any further such discussions should be moved to Charles' thread called 'Pseudoprimes'?

It doesn't bother me. It is normal behavior around here

Quote:

Originally Posted by J.F.

Yes a paper is now on the agenda, I got persuaded. Followup is planned for later this summer. WraithX and Jeff are contributing too, covering the verification efforts.
As Danaj noted, 64-bit is a rather nice bound mainly because of assembly optimizations.
Henryzz: a ballpark estimate for amount of work spent would be 70 CPU years (by me at least, in 2008, not sure about WraithX/Jeff).

Your paper is something to look forward to and, wow, that was a lot of cycles.

CRGreathouse · 2013-05-31, 21:37

Quote:

Originally Posted by J.F.

Yes a paper is now on the agenda, I got persuaded.

Excellent, please keep us informed! I look forward to reading it.

henryzz · 2013-06-01, 22:41

Quote:

Originally Posted by J.F.

Henryzz: a ballpark estimate for amount of work spent would be 70 CPU years (by me at least, in 2008, not sure about WraithX/Jeff).

Doesn't sound insane. A boinc project could take it several bits further if needed.

jcrombie · 2013-06-01, 23:15

Quote:

Originally Posted by paulunderwood

I have added a trial division option. The results field now blanks if there is a change to the inputs. The time taken is also displayed. The fields have been enlarged -- I hope this is okay for smart phone displays

Version 0.5:

tests redone for version 0.5:

Iphone 5, Safari
p201 693 ms 1062 ms with second test checked
p1001 69877 ms 106094 ms with second test checked

less dusty now Blackberry Playbook
p201 2257 ms 3045 ms with second test checked
p1001 self-aborts as before

for the smart phone, all fields are visible, no complaints

paulunderwood · 2013-06-02, 00:46

Thanks for the timings.

I am going to look into going from 15 bit array arithmetic to 24 bits again. It would slash running times greatly...

Mini-Geek · 2013-06-02, 01:59

Version 0.5:
40767ms in Chrome on Galaxy S3
84025ms (!) in Dolphin on Galaxy S3

12650ms in Chrome on i5-750/Windows 7

Slower than the last one I tried, and oddly enough, Dolphin now runs twice as slow as Chrome on my Android.

paulunderwood · 2013-06-02, 02:22

Thanks again, Mini-Geek, for the timings. I cannot think of any reason why the latest code is any slower than versions 0.3 and 0.4. Perhaps your S3 was doing something else in the background.

After some research on the net, I have found a trick which is way faster than the standard "Math.floor()" function. I shall use "~~(a/b)". Expect a 4 times speed up for the 24 bit version after I coded it up

paulunderwood · 2013-06-02, 06:46

I managed to code up a 24 bit version using the "~~(a/b)" trick as opposed to the very sluggish Math.floor() function. It worked with Internet Explorer 8 on 32-bit XP running on VirtualBox, given the previously linked hax from Microsoft; For p1001 it took 468414ms. I got some more realistic timings for other browsers with native Linux on this 2.7Ghz core2 box:

Epiphany 2.30.6:
28168ms -- Version 0.5
18121ms -- Version 0.6

FireFox 21.0:
8197ms -- version 0.5
3757ms -- version 0.6

Version 0.6:

Mini-Geek · 2013-06-02, 12:34

Quote:

Originally Posted by paulunderwood

Thanks again, Mini-Geek, for the timings. I cannot think of any reason why the latest code is any slower than versions 0.3 and 0.4. Perhaps your S3 was doing something else in the background.

It's also slower on my PC, by a comparable fraction. Is it faster for you?

paulunderwood · 2013-06-02, 15:16

Quote:

Originally Posted by Mini-Geek

It's also slower on my PC, by a comparable fraction. Is it faster for you?

No. Versions 0.3, 0.4 and 0.5 all use the same functions, as far as I can tell. Only new options were introduced -- 2-prp and trial division (resp.). They all have the same running times here (without options checked) for p1001, on both Epiphany and FireFox; and p201 in IE8 (VirtualBox). I saw a doubling in speed for IE8 and Version 0.6

2013-06-02, 02:22	#41
paulunderwood Sep 2002 Database er0rr 3,739 Posts	Thanks again, Mini-Geek, for the timings. I cannot think of any reason why the latest code is any slower than versions 0.3 and 0.4. Perhaps your S3 was doing something else in the background. After some research on the net, I have found a trick which is way faster than the standard "Math.floor()" function. I shall use "~~(a/b)". Expect a 4 times speed up for the 24 bit version after I coded it up Last fiddled with by paulunderwood on 2013-06-02 at 02:26

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PhD student needed for Paul Zimmermann's group	jasonp	Operation Kibibit	1	2017-09-07 19:54
Searching for Paul Underwood	diep	Lounge	3	2009-12-18 12:25
New data page	kar_bon	Riesel Prime Search	144	2008-10-21 10:27
Question about your page	OmbooHankvald	15k Search	2	2005-08-02 14:53
Paul Leyland's Mersenne factors table gone?	ixfd64	Lounge	2	2004-02-18 09:42

2013-05-31, 19:03	#34
J.F. Jun 2008 2³×3² Posts	Oh hi, Jan (Feitsma) here. It seems this thread was temporary hi-jacked, sorry Paulunderwood... maybe any further such discussions should be moved to Charles' thread called 'Pseudoprimes'? Yes a paper is now on the agenda, I got persuaded. Followup is planned for later this summer. WraithX and Jeff are contributing too, covering the verification efforts. As Danaj noted, 64-bit is a rather nice bound mainly because of assembly optimizations. Henryzz: a ballpark estimate for amount of work spent would be 70 CPU years (by me at least, in 2008, not sure about WraithX/Jeff).

2013-06-02, 00:46	#39
paulunderwood Sep 2002 Database er0rr 3,739 Posts	Thanks for the timings. I am going to look into going from 15 bit array arithmetic to 24 bits again. It would slash running times greatly...

2013-06-02, 01:59	#40
Mini-Geek Account Deleted "Tim Sorbera" Aug 2006 San Antonio, TX USA 17·251 Posts	Version 0.5: 40767ms in Chrome on Galaxy S3 84025ms (!) in Dolphin on Galaxy S3 12650ms in Chrome on i5-750/Windows 7 Slower than the last one I tried, and oddly enough, Dolphin now runs twice as slow as Chrome on my Android.