Feedback for new MPQS utility sought

[roger]

That's probably the quickest solution.

I don't have the number on this computer, so I will give it on the next post.
It is a "HomePrime" number, created through the factors of a previous number.

Thanks,

Roger

[roger]

The number is 310142030708790337224170415139151719079882696813129099039682740447879153219049216036673861532396661624530485784976701
and has two small factors 5507 and 105940727.
Remaining C105 : 531597097219941152928760691097467089807703303866657008820797579300224791923696034690278228478211191439609
Just a note : I have factored through Alpertron's ECM applet 2007 curves (above 30 or 35 digits).

Thanks to all,

Roger

[Mystwalker]

Hi Roger,

If no one else shows up, I should be able to factor that composite this weekend.

[Shiva]

Originally Posted by Mystwalker

Hi Roger,

If no one else shows up, I should be able to factor that composite this weekend.

Hi,

I started working on this one this morning. I should hopefully finish it tomorrow.

Dennis

[roger]

Great Thanks to Shiva, MystWalker, and especially JasonP, everyone else who have been helping me on the factoring problems on MersenneForum

[Shiva]

Originally Posted by roger

The number is 310142030708790337224170415139151719079882696813129099039682740447879153219049216036673861532396661624530485784976701
and has two small factors 5507 and 105940727.
Remaining C105 : 531597097219941152928760691097467089807703303866657008820797579300224791923696034690278228478211191439609
Just a note : I have factored through Alpertron's ECM applet 2007 curves (above 30 or 35 digits).

Thanks to all,

Roger

Hi Roger,

Msieve mpqs gives:
prp43 factor: 2167753016229889965714682414298485438968899
prp63 factor: 245229550248525794245694689384198265019333183525485329987510291

Enjoy!
Dennis

[roger]

Thank you Shiva!



A long awaited answer!

Roger

[BlisteringSheep]

Using trilliwig's reference numbers and msieve-1.1.16:

Linux, 3.2 GHz Xeon, -fpmath=sse

Number       digits  gcc-3.4.6   gcc-4.1.1
-----------------------------------------
(6^67-1)/5    52      0:00:02    0:00:03
(10^59-1)/9   59      0:00:12    0:00:12
(3^137+1)/4   65      0:00:38    0:00:36
(10^71-1)/9   71      0:01:59    0:01:54
(12^71+1)/13  76      0:07:30    0:07:31
(10^83-1)/9   83      0:33:07    0:31:19

Linux, 3.2 GHz Xeon, -fpmath=387

Number       digits  gcc-3.4.6   gcc-4.1.1
-----------------------------------------
(6^67-1)/5    52      0:00:03    0:00:03
(10^59-1)/9   59      0:00:12    0:00:15
(3^137+1)/4   65      0:00:37    0:00:51
(10^71-1)/9   71      0:02:05    0:02:28
(12^71+1)/13  76      0:07:23    0:09:49
(10^83-1)/9   83      0:31:31    0:41:05

Linux, 2.0 GHz PPC970

Number       digits  gcc-3.4.6   gcc-4.1.1
-----------------------------------------
(6^67-1)/5    52      0:00:02    0:00:02
(10^59-1)/9   59      0:00:10    0:00:10
(3^137+1)/4   65      0:00:34    0:00:39
(10^71-1)/9   71      0:01:44    0:02:09
(12^71+1)/13  76      0:06:55    0:08:52
(10^83-1)/9   83      0:31:06    0:39:39

[jasonp]

Originally Posted by BlisteringSheep

Using trilliwig's reference numbers and msieve-1.1.16:

Ouch, this is rather disheartening, especially since the time-critical parts of the sieving routines don't care about floating point at all.

I assume that everything was also compiled with -march=pentium4? Do the runtimes look similar or worse when -fpmath= is not specified?

jasonp

[BlisteringSheep]

Jason,

The Xeon tests were all compiled with -O3 -fomit-frame-pointer -DNDEBUG -march=pentium4 -DHAVE_CMOV -mtune=pentium4 -mmmx -msse -msse2 in addition to the -fpmath flags. I also ran tests with -fpmath=sse,387 and the timings were much worse.

Here are the results without setting -fpmath:

Number       digits  gcc-3.4.6   gcc-4.1.1
-----------------------------------------
(6^67-1)/5    52      0:00:02    0:00:03
(10^59-1)/9   59      0:00:11    0:00:17
(3^137+1)/4   65      0:00:36    0:00:45
(10^71-1)/9   71      0:01:50    0:02:42
(12^71+1)/13  76      0:07:11    0:08:59
(10^83-1)/9   83      0:33:17    0:43:44

What has really surprised me is the poorer performance for gcc-4.1.1, both on the Xeon and the PPC970. With sr2sieve, gcc-4.1.1 gives much better performance, especially on the PowerPC.

I'd be happy to run other compile flag variants. I do also have a 3.2 GHz Nocona that I can compile and run in 64 bit mode on if you are interested. Just let me know what compilation flags you'd like me to try out.

[jasonp]

Originally Posted by BlisteringSheep

I'd be happy to run other compile flag variants. I do also have a 3.2 GHz Nocona that I can compile and run in 64 bit mode on if you are interested. Just let me know what compilation flags you'd like me to try out.

Without having investigated the slowdown, my guess right now is that a critical function doesn't get inlined, or a critical function has spills to memory using the newer gcc. If that's the case, then a binary compiled in 64-bit mode won't be appreciably slower using the newer gcc.

Could you compile with -march=nocona and try the same tests? I also have a local PPC970, so at least I can investigate that when I get a little time.

jasonp