To try out the OpenMP version of ECM 6.3 RC, I ran P-1 with B1=1e11, B2=1e17 with no factor. In stage 2, it tried to use nearly 80GB of memory, but -maxmem 60000 took care of that. (This was on a computer with 32 cores and 64 GB of memory.) The save file is attached if anyone else wants to play with it.

[QUOTE=jrk;211774]I'll reserve -np 120060,144000 for msieve poly search.[/QUOTE]

Here's a good one. I've stopped my search.
[code]n: 1013904588703098792884235195952095442985510080927831590157043860326308617127064242065552400948180775943692241149077853323277907440412871474510308638247384454807344424863
# norm 1.575426e-16 alpha -7.255157 e 3.631e-13
skew: 42588812.36
c0: -719217919196348359846912956443964771485253
c1: -481749404203163132755390356806146555
c2: -5680379388880476570796257423
c3: -9396379978052545977
c4: -12054458618516
c5: 126300
Y0: -380994574900600836897374235640648
Y1: 2024992138735802693
rlim: 67108863
alim: 67108863
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
[/code]
The parameters appear to be optimal after doing some test-sieving. Once ECM is finished, sieve the range of Q=20M to 85M on the algebraic side with siever 15e.

done 2000 curves at 11e7; no factor. bored now

[quote=fivemack;212447]done 2000 curves at 11e7; no factor. bored now[/quote]

Such semi primes cause the sequences to stall (rather causing that delay upon that subsequent iterations),
thus depriving people's interest from the sequence, rather than that going on smoothly :sad:

After a total of 17268 curves at 11e7 with no factor, I too am bored.

"All work and no play make Jack a dull boy."
There's a good (no kidding) poly to run, what are y'all sulking about? :max:

[QUOTE=Batalov;212514]There's a good (no kidding) poly to run, what are y'all sulking about? :max:[/QUOTE]
Well get to it!

Nah. I moved it for one iter. Now it's your guys turn. :missingteeth:

[SIZE=1][a semi-automatic translation of a 210-year old fable "The Fly" by Ivan Dmitriev, a senior contemporary of Pushkin.][/SIZE]

Bull with a plow on to rest trailed after labor;
And fly was sitting on his horns
They met another fly at the crossroads.
"Where are you coming from, sister?" - her question was,
And she, raising her nose, responsed:
"Where from?" - [B]We plowed![/B]

:showoff:

I've run a bit of [URL="http://en.wikipedia.org/wiki/Fermat%27s_factorization_method"]Fermat's factorization method[/URL] on the c169 using a Java program I wrote. (based off the pseudocode in the Wikipedia article, in case you're wondering what b2 means) I got to:
[code]a: 1006928293724582352836526965038799533765440853903125727459854729790360376341902560000,
b2: 5977655801632695444441602436412983106854477403507660666119163216019232575096079746255575137,
a-b: 1006928293724582352836526965038799533762995929404980090357154229083379038115617514689
[/code](note that b's fractional part is ignored for the a-b calculation)
So if I understand the article/math right, there are no factors of the c169 from a-b to the square root of the c169 (this is a-b and then the floor of the square root):
[code]1006928293724582352836526965038799533762995929404980090357154229083379038115617514689
1006928293724582352836526965038799533765440853903125727459854729790360376341899591737[/code]It took about 4 minutes total. I'm sure a more efficient program could've done the same thing in seconds, but I did this mainly as a curiosity. Besides, in the very unlikely even that a factor was waiting right there to be found, I could've saved everyone a lot of time GNFSing this!
BTW does anyone know of an efficient implementation of Fermat's factorization method or something else that, like it, is a quick search for factors near the square root of N?

2529... 2530... ... 2535... nice!

How long a c113 will take these days? 15 minutes? :rolleyes:

[SIZE=1][COLOR=lemonchiffon]It's about 10cpu-hrs, but divided by some meager 40 cpus or whatnot...?[/COLOR][/SIZE]