mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Aliquot Sequences (https://www.mersenneforum.org/forumdisplay.php?f=90)
-   -   Aliqueit.exe discussion (https://www.mersenneforum.org/showthread.php?t=11618)

bsquared 2009-03-20 02:21

[quote=mklasson;166040] Well then, get [URL="http://mklasson.com/aliquot.php"]aliqueit v1.02[/URL].


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.

[/quote]

Yep, works fine for me.

[quote=mklasson;166040]
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[/code] 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[/code] for 32.9 at c100 and 37.6 at c120.

[/quote]
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=mklasson;166040]
To test the performance on smaller numbers I ran the Ben-chmark of doing the first 1225 lines of sequence 10212:
[/quote]

:cool:

bsquared 2009-03-20 02:33

[quote=mklasson;166040]Well then, get [URL="http://mklasson.com/aliquot.php"]aliqueit v1.02[/URL].
[/quote]

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?

mklasson 2009-03-20 02:44

[QUOTE=bsquared;166046]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.[/QUOTE]

Goody, thanks.

[code]
digits #curves
45 10
50 15
55 20
60 30
65 40
[/code]
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. :smile:

[QUOTE=bsquared;166050]Is there a way for aliqueit to intercept the cntl-c and stop it's execution instead?[/QUOTE]

Alas, I have no idea about that. It's been a long time since I did any linux coding...

smh 2009-03-21 08:45

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.

mdettweiler 2009-03-21 10:50

[quote=smh;166167]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.[/quote]
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. :smile:

mklasson 2009-03-21 12:53

[QUOTE=smh;166167]Can i make one more request?[/quote]

Please do, I'm happy to hear it.

[QUOTE=mdettweiler;166175]Open Task Manager and kill the ECM process (or, use pgrep/pkill under Linux)[/QUOTE]

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. :down:

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

Here you go: [url=http://mklasson.com/aliquot.php]aliqueit v1.03[/url].

+ 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.

smh 2009-03-21 17:48

[QUOTE=mdettweiler]Open Task Manager and kill the ECM process (or, use pgrep/pkill under Linux)[/quote]Thanks, i never thought of that.
[QUOTE=mklasson;166180]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.[/QUOTE]This would be fine for me.[QUOTE=mklasson;166180]Aah, I'll just add the switch anyway... Saves a few seconds manual labor. :smile:[/quote]Even better, thanks.[QUOTE=mklasson;166180]
+ prints the size of the composite we're currently processing.[/quote]Thanks, this is helpful.

10metreh 2009-03-22 07:39

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.

smh 2009-03-22 09:39

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..."[/CODE]

mklasson 2009-03-22 14:02

[QUOTE=10metreh;166238]1. A full t30 is not needed on a C93.[/quote]

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=10metreh;166238]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.[/QUOTE]

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 [b]factor sizes[/b] at c70 and c95. What I really want is appropriate [b]time[/b] 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. :smile:

mklasson 2009-03-22 14:16

[QUOTE=smh;166245]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..."[/CODE][/QUOTE]

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. :lol: 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.


All times are UTC. The time now is 09:07.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.