[quote=Mini-Geek;203624]BTW is it my imagination, or was PRPnet derived from ECMNET? (or something like that?) All the config files and stuff are very similar.[/quote]
Yes, it was. By now they don't share much underlying code, but the earliest PRPnet versions resembled ECMnet quite a bit. Even now, though, there's at least one (rather benign) leftover that I've caught: when the SMTP server settings are configured incorrectly, it will say something along the lines of "SMTP settings configured incorrectly. Factors will not be mailed to x" where x is the email address configured in the server.

[quote=Mini-Geek;203624]So, if I get you right:
aliqueit uses system()
system() makes the pipes work as intended
Python scripts can't use system()
so a Python script can't use pipes
so this script can't use the same line that aliqueit would to pass work to GMP-ECM[/quote]No, this is not what I meant.
[quote]If that's right, then instead of using pipes, pass GMP-ECM a file. e.g. write the number to "ecm-num.txt" then do ECM with "ecm [options] [B1] < ecm-num.txt > out-file.txt".
Edit: on rereading, maybe you mean that the python script isn't told the entire line, but just the parameters it's passed?[/quote]Almost, but not quite. Since aliqueit passes control directly to system() - not via a pipe - Python would not be told ANYTHING when this command is invoked. In other words, there is no pipe involved so Python has nothing to interceept.
[quote]Hence my:And he seems willing to do it.[/quote]I would say willing to consider doing it :smile:

But not if it requires changes to aliqueit, as I believe it probably does.

Brian

[quote=Brian Gladman;203651]Almost, but not quite. Since aliqueit passes control directly to system() - not via a pipe - Python would not be told ANYTHING when this command is invoked. In other words, there is no pipe involved so Python has nothing to interceept.[/quote]
Why, with the exact same line, would Python not be told anything at all, but GMP-ECM be told everything? (as it must for it to work as intended) That doesn't make sense to me.

[quote=Mini-Geek;203679]Why, with the exact same line, would Python not be told anything at all, but GMP-ECM be told everything? (as it must for it to work as intended) That doesn't make sense to me.[/quote]

I can now see that we are talking at cross purposes. I have been discussing a Python script directly invoked by aliqueit. You are talking about a script that masquerades as ECM and is hence invoked as a step in the pipes establsihed by aliqueit's system() call.

I agree that it would be possible to do what you suggest but I suspect that it might get messy because the script will run below two other process levels (alliqueit and system). I would not be keen to do it this way but I would be happy to offer any advice you need on Python issues if you want to give it a try.

Brian

Benchmark: c133 with lpbr/a 27 and 28
 

I just did a benchmark - c133 cofactor of aliquot sequence 10212, index 2267 with 27 and 28 bit large primes (mfbr/a = lpbr/a*2), using 64-bit gnfs-lasieve4I13e (core2duo @ 2.0 GHz, Ubuntu 9.04 64 bit):

Poly:
[CODE]n: 5335366387062594103281599506619078830675568770597674764072096981029494235489350569590888813457656823560321885511353040519174462222557
skew: 863842.14
Y0: -43590657298344915874817701
Y1: 467844431521753
c0: 3052516397340263636960237838715200
c1: 29100578051888094818724416280
c2: 36523592624186545117942
c3: -123602480596394341
c4: -18461007596
c5: 33900
rlim: 5800000
alim: 5800000
lpbr: 27 #(or 28)
lpba: 27 #(or 28)
mfbr: 54 #(or 56)
mfba: 54 #(or 56)
rlambda: 2.6
alambda: 2.6
[/CODE]

Result with lpb27:

[CODE]./gnfs-lasieve4I13e -a alq10212.2267.poly -o c133.test27.out -f 5800000 -c 2000
total yield: 2939, q=5802023 (0.04381 sec/rel)

./gnfs-lasieve4I13e -a alq10212.2267.poly -o c133.test27a.out -f 7000000 -c 2000
total yield: 2517, q=7002019 (0.04831 sec/rel)

./gnfs-lasieve4I13e -a alq10212.2267.poly -o c133.test27b.out -f 3000000 -c 2000
Warning: lowering FB_bound to 2999999.
total yield: 2516, q=3002003 (0.04286 sec/rel)
[/CODE]

result with lpb28:
Note: "score27" is calculated to compare with lpb27, thus relations/2 and sec/rel*2

[CODE]./gnfs-lasieve4I13e -a alq10212.2267b.poly -o c133_test28.out -f 5800000 -c 2000
total yield: 5534, q=5802023 (0.02416 sec/rel) (score27: 2767; 0.04832)

./gnfs-lasieve4I13e -a alq10212.2267b.poly -o c133_test28a.out -f 7000000 -c 2000
total yield: 4839, q=7002019 (0.02690 sec/rel) (score27: 2420; 0.05380)

./gnfs-lasieve4I13e -a alq10212.2267b.poly -o c133_test28b.out -f 3000000 -c 2000
Warning: lowering FB_bound to 2999999.
total yield: 4678, q=3002003 (0.02212 sec/rel) (score27: 2339; 0.04424)
[/CODE]

Conclusion: assuming, that 28 bit large primes needs twice as much relations as 27 bit large primes, [B]lpbr/a 27 (and mfbr/a 54) is [I]still faster than lpbr/a 28[/I] for c133[/B]. I would encourage test sieving for testing whether 27 or 28 bit large primes is faster up to c135 or even c136.

another question is should we be basing our parameters on digits or polynomial quality

Andi47, I am extremely interested in your lpb27 and lbp28 benchmarks for numbers in the C130-C135 range. I happen to be factoring several numbers in this range using factmsieve.py and I'd like to try your altered lpb27 parameters and seeing what improvement occurs on my 32 Win XP OS.

I normally start factmsieve.py with a file like c132.n containing only one line with the n to be factored. How does one pass in the altered parameters to factmsieve.py? I'm assuming I need to pass the following:

lpbr: 27
lpba: 27
mfbr: 54
mfba: 54

Can I add the above to c132.n?

[QUOTE=tmorrow;203842]Andi47, I am extremely interested in your lpb27 and lbp28 benchmarks for numbers in the C130-C135 range. I happen to be factoring several numbers in this range using factmsieve.py and I'd like to try your altered lpb27 parameters and seeing what improvement occurs on my 32 Win XP OS.

I normally start factmsieve.py with a file like c132.n containing only one line with the n to be factored. How does one pass in the altered parameters to factmsieve.py? I'm assuming I need to pass the following:

lpbr: 27
lpba: 27
mfbr: 54
mfba: 54

Can I add the above to c132.n?[/QUOTE]

I have not tried to use factmsieve.py yet, so I don't know anything about how to pass the parameters to it.

Up to now I have used lpbr/a 27 amd mfbr/a 54 for c131's and c132's, but I don't have any benchmarks for these. My benchmark on a c133 posted above suggests that the crossover between lpbr/a 27 and 28 is a little bit [I]above[/I] c133, so I guess that you can safely take the parameters you posted for c131 and c132.

For c130, the parameter file of factmsieve.[B]pl[/B] suggests lpbr/a 27 and mfbr/a 51(!), but I don't have benchmarked this against mfbr/a 52...54 either.

For c136 I have read somewhere in the forum (sorry, I don't remember where), that lpbr/a 27 (needs ~15M rels??) is slower than lpbr/a 28 (needs 23M rels?), so I think the crossover is somewhere around c134 or c135.

Edit: BTW if you are about to factor a c132, I would suggest that - once you have a poly - you create two poly files, one with lpb27 and one with lpb28. Then, run

[CODE]gnfs-lasieve4I13e -a c132_lpb27.poly -o test27.out -f <start of the range> -c 2000

and

gnfs-lasieve4I13e -a c132_lpb28.poly -o test28.out -f <start of the range> -c 2000
[/CODE]

for ranges starting e.g. at 3M, 5.4M (=alim), 7M. Take the total yield and the timings for both. Note that lpb28 needs about twice as much relations as lpb27, so divide the yield of the "lpb28"-runs by two and multiply the "sec./rels"-number of the lpb28-runs with two to get the "lpb27-scores". Now you can directly compare, which run is faster and which one produces a higher yield.

I don't think you can add these to the *.n file. As far as I can see from the code, you can add them to the *.poly file.

Brian

[QUOTE=Mini-Geek;203624]ECMNET looks good for what is was made for: splitting up the factoring of a semi-static list of some numbers over many CPUs. But it's not geared for, and would really be overkill for, (assuming you can even get it to run an aliquot sequence, one way or another) something like small aliquot sequences.[/QUOTE]I'm still missing something.

Why can't you load up an ECMNET server with a reasonable number of integers to be factored and leave it to get on with it. "Reasonable" depends on how many clients you are running and could be anywhere between a few dozen and a few thousand. It's not as if aliquot sequences are in short supply.

"Leave it to get on with it" means collecting factors by email from the ECMNET server until the number of remaining composites has fallen enough (or the rate of arrival of factors is too low for comfort). At that point, replenish the server with new integers from new sequences and decide what to do with the old composites --- either leave them in the server or remove them for factoring with other approaches --- NFS or QS presumably.

After a little time spent getting the feel for how things work in practice, you shouldn't need to do any kind of server administration for several weeks, or several months, at a time.


Paul

[QUOTE=xilman;203875]<snip>[/QUOTE]

I know that schickel uses an ECMNET server to run ECM on his sequences, which are all quite large. It is fine for running aliquot sequences. However, the aliquot sequence project is currently structured completely differently: people reserve whole sequences, not just composites for NFS, with a bit of ECM added in, like the Homogeneous Cunninghams project. I'm not saying that ECMNET wouldn't work for aliquot sequences; just that it would eliminate the element of fun that constitutes a downdriver run.