20090318, 14:15  #12 
Feb 2004
402_{8} Posts 
Ah, gcc doesn't like
Code:
found_factor( mpz_class( trial_primes[j] ), factors ); Code:
mpz_class tmp( trial_primes[j] ); found_factor( tmp, factors ); Sorry for spamming this thread btw. EDIT: btw, just noticed something odd about yafu: Code:
>yafu siqs(rho(1813647130602161341)) Last fiddled with by mklasson on 20090318 at 14:17 Reason: btw 
20090318, 14:50  #13  
"Ben"
Feb 2007
2^{6}×3×17 Posts 
Quote:
I've attached the modified .cc file. Agreed, mods feel free to move this stuff where appropriate... including maybe the stuff below into the yafu thread. Quote:
 ben Last fiddled with by bsquared on 20090318 at 14:51 Reason: added attachment 

20090318, 16:14  #14 
Feb 2007
3^{3}×5 Posts 
It compiled for me with 'g++ aliqueit.cc lgmp' where aliqueit.cc is the modified file from post #17. It is currently halfway through 800 ECM curves on a C104. Looking forward to see if it switches to ggnfs properly.

20090318, 16:56  #15 
Feb 2004
2×3×43 Posts 
I hope you have changed the ggnfs_cmd setting in aliqueit.ini to something appropriate for your system. You'll also need to change the ggnfs_clean_cmd if you want the ggnfs work files to be deleted upon successful completion.

20090318, 18:01  #16 
Feb 2007
3^{3}·5 Posts 
yes, It appeared that I needed to specify the full path for it to work, even though I had put the contents of my ggnfs/bin folder into the aliqueit101 folder. It started looking for a polynomial now.

20090319, 01:33  #17  
Feb 2004
2·3·43 Posts 
Quote:
I did some experimental benchmarking today to find good ecm levels for <65 digits. It's a shame it's not that easy for c100+. Hm, come to think of it, as nfs has better asymptotics shouldn't the ecm scaling factor for nfs be smaller than the corresponding one for qs? I.e. using 2/9*N for qs and 3/9*N for nfs seems inherently wrong. I realise they're both fuzzy guidelines, but don't you agree? Maybe something like 11+1/5*N would be better for nfs? Or maybe I'm just wrong. In any case, how much ecm do you people often running big nfs jobs normally do? 

20090319, 04:45  #18  
"Ben"
Feb 2007
2^{6}·3·17 Posts 
Quote:
I agree that spending half the time a gnfs run would have taken on ecm seems excessive, but I don't have any data to suggest a better choice. Over a large number of factorizations, maybe something like 1/3 the time, max, would be better? Sorry I can't be more concrete. 

20090319, 08:14  #19  
Nov 2008
2×3^{3}×43 Posts 
Quote:


20090319, 19:12  #20 
Just call me Henry
"David"
Sep 2007
Cambridge (GMT)
13052_{8} Posts 

20090319, 20:36  #21 
Feb 2004
402_{8} Posts 
I'm still not really satisfied. For a c120 I'd then do ecm to a 34.3digit factor level. That's about 1.25 cpuhours work, whereas the ggnfs job takes ~2025 cpuhours. ECMing for just 1/16th of the sieve time seems a little frugal. Ben mentioned a few posts above a tentative recommendation of ~1/3 the sieve time, and I noticed in another thread fivemack said he does about 1/4 (http://www.mersenneforum.org/showpos...&postcount=148).
Any simple fraction*N factordigits ecm rule probably matches reality pretty badly for one size or another, assuming a constant ratio of ecm_time to sieve_time is correct, which I'm not even sure it is. Ultimately we want to find a factor as quickly as possible. Running gnfs guarantees we'll find it after a certain period of time, while doing ecm gives us a chance to maybe find it sooner. Doing ecm yields progressively worse returns though. About all I can say is that we probably should spend more than zero time ecming, but less than the full sieve time. I still hope someone can step up with some solid math and explain the reasoning behind it and/or point to a good chunk of empirical data. Maybe something taking into consideration the probability of our composite having a factor of a certain size and the probability per time unit of finding such a factor with ecm. The gmpecm readme file gives at least a part of the solution in the quote "After performing the expected number of curves from Table 1, the probability that a factor of D digits was missed is exp(1), i.e., about 37%." Anyway, surely there are wizards lurking around here for whom such tricks is a trifling matter. In the meantime I'll be releasing a new version soon that is a lot faster for small numbers (using experimentally determined better ecm limits and letting yafu work its pollard rho magic), and hopefully a little better for bigger numbers. Without knowing what the optimal targets even are for bigger numbers though, it's hard to say. Anyway, you're of course all welcome to alter the config/source and use whatever limits you prefer. 
20090320, 00:34  #22 
Feb 2004
2·3·43 Posts 
Well then, get aliqueit v1.02.
+ much faster for small numbers, and probably faster for bigger numbers, i.e. better ecm tuning. + compiles and runs under linux now. Thanks Ben. + detects when a sequence merges with an earlier sequence. Setting "detect_merge = false" can be used to skip this, should you want to try and hit the possibly imminent termination anyway. + hides yafu/msieve screen output for composites < <hide_output_limit> digits. Unwanted output is redirected to <null_device>. 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 nonwindows. 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 gnfs I got Code:
9.4f + 0.235f * input_digits To test the performance on smaller numbers I ran the Benchmark of doing the first 1225 lines of sequence 10212: Code:
aliqueit v1.01: 1m38s Ben's unofficial yafualiquot: 1m18s aliqueit v1.02: 56s 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Resuming aliqueit  johnadam74  Aliquot Sequences  4  20160328 12:32 
Apparent aliqueit issue with specifying factors  pakaran  Aliquot Sequences  2  20150912 23:10 
Using Several Instances of Aliqueit for a large gnfs job  EdH  Aliquot Sequences  6  20111213 18:58 
Setting up aliqueit  science_man_88  Aliquot Sequences  185  20111108 12:18 
Tried out aliqueit.exe: ggnfs failing  Greebley  Aliquot Sequences  35  20100213 15:23 