mersenneforum.org Aliqueit.exe discussion
 Register FAQ Search Today's Posts Mark Forums Read

2009-03-20, 02:21   #23
bsquared

"Ben"
Feb 2007

CDA16 Posts

Quote:
 Originally Posted by mklasson Well then, get aliqueit v1.02. Hopefully it still compiles under linux... I can't test it, but I don't think you'll have any problems. The config file contains a few OS specific settings at the top that you'll need to change when running under non-windows.
Yep, works fine for me.

Quote:
 Originally Posted by mklasson I ended up targeting ecm_time = 1/4*qs_time (or gnfs_time) by rummaging through logs of previous factorisations and constructing linear expressions for fitting the ecm efforts properly at c70 and c95 for qs and c100 and c120 for gnfs. Assuming it's a good idea to do a quarter ecm relative to the qs/gnfs time this version should perform better than previous ones on c70+. The timings are for my machine, a core i7, so ymmv. The estimates are probably decent on most machines. For qs I ended up with Code: 0.448f * input_digits - 11.26f for 20.1 at c70 and 31.3 at c95. These values are the maximum factor size we will search for using the recommended ecm steps in gmp-ecm's readme. For gnfs I got Code: 9.4f + 0.235f * input_digits for 32.9 at c100 and 37.6 at c120.
These look like decent relationships, nice work! What external (i.e. non-yafu) ecm work is done for < 70 digits? I could parse the .ini, I guess, but I'm lazy tonight.

Quote:
 Originally Posted by mklasson To test the performance on smaller numbers I ran the Ben-chmark of doing the first 1225 lines of sequence 10212:

2009-03-20, 02:33   #24
bsquared

"Ben"
Feb 2007

329010 Posts

Quote:
 Originally Posted by mklasson Well then, get aliqueit v1.02.
If you don't have access to a linux system then maybe you can't do anything about this, but I have one request. When I try to kill aliqueit when it's running via cntl-c it instead kills the program (yafu/msieve/ecm) that is running at that moment, and aliqueit immediately continues on and launches another factorization. So I have to cntl-z to the background, ps for the process IDs, kill the factorization job, then kill aliqueit, then fg aliqueit. Quite a process to stop the thing from running. Is there a way for aliqueit to intercept the cntl-c and stop it's execution instead?

2009-03-20, 02:44   #25
mklasson

Feb 2004

2×3×43 Posts

Quote:
 Originally Posted by bsquared Yep, works fine for me. These look like decent relationships, nice work! What external (i.e. non-yafu) ecm work is done for < 70 digits? I could parse the .ini, I guess, but I'm lazy tonight.
Goody, thanks.

Code:
digits #curves
45 10
50 15
55 20
60 30
65 40
Starting with B1=1 and auto-incremented using "ecm -I 1". Starting a little higher than 1 could probably shave another ms off the time.

Quote:
 Originally Posted by bsquared Is there a way for aliqueit to intercept the cntl-c and stop it's execution instead?
Alas, I have no idea about that. It's been a long time since I did any linux coding...

 2009-03-21, 08:45 #26 smh     "Sander" Oct 2002 52.345322,5.52471 29·41 Posts Can i make one more request? I would like to be able to skip the ecm stage when i resume a sequence and straight away start with yafu or msieve. I have composites that have quite a bit of ecm done on them already and searching for 25 or 30 digit factors wouldn't make sense. Of course i could crack the composite first, but that way i won't be able to run the sequence unatended over night.
2009-03-21, 10:50   #27
mdettweiler
A Sunny Moo

Aug 2007
USA (GMT-5)

624910 Posts

Quote:
 Originally Posted by smh Can i make one more request? I would like to be able to skip the ecm stage when i resume a sequence and straight away start with yafu or msieve. I have composites that have quite a bit of ecm done on them already and searching for 25 or 30 digit factors wouldn't make sense. Of course i could crack the composite first, but that way i won't be able to run the sequence unatended over night.
Open Task Manager and kill the ECM process (or, use pgrep/pkill under Linux); aliqueit will see that ECM has ended, find no factors in the log, and proceed on (either to QS, or to the next stage of ECM). If more stages of ECM are considered necessary by aliqueit, you'll need to kill those, too, but once you've gotten to the last one (should be only two or three at maximum most of the time) it will then consider ECM done and progress on to Yafu/msieve for QS.

2009-03-21, 12:53   #28
mklasson

Feb 2004

25810 Posts

Quote:
 Originally Posted by smh Can i make one more request?
Please do, I'm happy to hear it.

Quote:
 Originally Posted by mdettweiler Open Task Manager and kill the ECM process (or, use pgrep/pkill under Linux)
Yeah, this is what I've been doing as well. Is that ok for you Sander? I could add a switch to do what you want but the code would be kinda ugly.

I often stop when I see a ggnfs-pol51 running, "manually" find a better poly with msieve instead, and then restart. I would like to use msieve-polyfind in the automation instead but it's currently crashing too often for me to be usable unattended.

Aah, I'll just add the switch anyway... Saves a few seconds manual labor.

Here you go: aliqueit v1.03.

+ cmdline arg "-e" skips ecm on the current iteration and goes straight to qs/gnfs. Further iterations use ecm normally.

+ prints and logs a cheerful msg if an ecm factor >= <neat_factor_limit_ecm> digits is found.

+ prints the size of the composite we're currently processing.

* scientifies printed B1 values. 1000000 -> 1e6.

* fixed a potential bug where we'd ecm forever ("ecm -c 0") or until we found a factor. It never actually happened, but it could have if the ecm level formulas had looked different.

* changed the default <big_ecm_cutoff> to 65 instead of 70. This results in a little more ecm being done for c65-c69.

2009-03-21, 17:48   #29
smh

"Sander"
Oct 2002
52.345322,5.52471

100101001012 Posts

Quote:
 Originally Posted by mdettweiler Open Task Manager and kill the ECM process (or, use pgrep/pkill under Linux)
Thanks, i never thought of that.
Quote:
 Originally Posted by mklasson Yeah, this is what I've been doing as well. Is that ok for you Sander? I could add a switch to do what you want but the code would be kinda ugly.
This would be fine for me.
Quote:
 Originally Posted by mklasson Aah, I'll just add the switch anyway... Saves a few seconds manual labor.
Even better, thanks.
Quote:
 Originally Posted by mklasson + prints the size of the composite we're currently processing.

Last fiddled with by smh on 2009-03-21 at 17:49

 2009-03-22, 07:39 #30 10metreh     Nov 2008 2×33×43 Posts I think aliqueit's ECM limits need improving. I am currently working on a C93 from iteration 1985 of sequence 130396, and before starting msieve, aliqueit proceeded to do a full t30 and then 73 curves at 1M! 1. A full t30 is not needed on a C93. 2. (This is a new one) If ECM needs to be run to 32.5 digits, that does not mean that you have to run half t35. I would guess about 1/3 t35 would be better.
 2009-03-22, 09:39 #31 smh     "Sander" Oct 2002 52.345322,5.52471 22458 Posts OK, one more request. Not that important, just to make our live a little easier ;-) The aliqueit.log contains all ecm curves. This makes the log quite big and information is hard to find. Would it be possible to just print something like Code: "c103: ran 430 ecm curves at B1=25e4..." "c103: ran 651 ecm curves at B1=1e6..."
2009-03-22, 14:02   #32
mklasson

Feb 2004

4028 Posts

Quote:
 Originally Posted by 10metreh 1. A full t30 is not needed on a C93.
On what do you base this and what would you prefer instead? I'm not saying you're wrong, it's just that if you want to spend about 1/4 of the qs time on ecm that's roughly the amount of ecm you'll have to do. Again, I'm not sure if 1/4 time is the best figure but it seems decent enough and I have yet to find some solid justification for any specific amount. Please show me the light of reason if you're hoarding it.

Quote:
 Originally Posted by 10metreh 2. (This is a new one) If ECM needs to be run to 32.5 digits, that does not mean that you have to run half t35. I would guess about 1/3 t35 would be better.
Good point. The estimates (and reasoning behind them) are rough enough that I don't really think it matters though. I certainly don't know whether it's best to spend 1/3, 1/4, or 1/5 of the qs time ecming a c93 for example. Furthermore, the way I get the factor digit estimate in the first place is via linear inter-/extrapolation from appropriate factor sizes at c70 and c95. What I really want is appropriate time scaling though, with the time approximately doubling for every 3 input digits (for qs). The way the ecm table is set up with progressively harder and more curves for each digit level converts the linear factor size limits into something resembling exponential time limits.

The net effect of all this is definitely not the perfect scaling sought, and you're right, removing the linearity between 30 and 35 would be good. I think ultimately the whole linear scaling of factor size needs to go though, and be replaced with proper time scaling and data for how long a curve takes for a given B1 and input size. But maybe this is overkill given that I still don't know whether ecm_time/qs_time = 1/4 is a fundamentally good idea.

2009-03-22, 14:16   #33
mklasson

Feb 2004

2·3·43 Posts

Quote:
 Originally Posted by smh OK, one more request. Not that important, just to make our live a little easier ;-) The aliqueit.log contains all ecm curves. This makes the log quite big and information is hard to find. Would it be possible to just print something like Code: "c103: ran 430 ecm curves at B1=25e4..." "c103: ran 651 ecm curves at B1=1e6..."
I know what you mean... The reason I want the ecm logs saved is I'm naively hoping to get lucky and find a humongous ecm record factor. It would be a shame to not have the sigma saved when that happens.

I could skip saving the ecm log if no factor was found though, and only print a line like you suggested. That'd cut down heavily on the spam. Sounds like a good compromise, and very easy to implement.

 Similar Threads Thread Thread Starter Forum Replies Last Post johnadam74 Aliquot Sequences 4 2016-03-28 12:32 pakaran Aliquot Sequences 2 2015-09-12 23:10 EdH Aliquot Sequences 6 2011-12-13 18:58 science_man_88 Aliquot Sequences 185 2011-11-08 12:18 Greebley Aliquot Sequences 35 2010-02-13 15:23

All times are UTC. The time now is 03:47.

Mon Sep 28 03:47:31 UTC 2020 up 18 days, 58 mins, 0 users, load averages: 1.34, 1.29, 1.39