20090404, 05:27  #1 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9,391 Posts 
Msieve 1.41 Feedback
> diff ../msieve1.40/include/mp.h include/mp.h
504,507c504,505 < if (a >= b) < return a  b; < else < return a  b + p;  > uint32 t = a  b; > return t += ((t >> 31) * p); ...and subsequently (64bit linux)... multiply complete, coefficients have about 2.64 million bits error: relation product is incorrect algebraic square root failed reading relations for dependency 5 read 37937 cycles cycles contain 140259 unique relations read 140259 relations multiplying 109340 relations multiply complete, coefficients have about 2.63 million bits error: relation product is incorrect algebraic square root failed ... 
20090404, 07:00  #2 
Oct 2004
Austria
2×17×73 Posts 
Which lower composite size limit for GNFS poly selection does v.1.41 have?

20090404, 07:22  #3 
Nov 2008
2·3^{3}·43 Posts 

20090404, 07:41  #4 
Sep 2004
1025_{8} Posts 
I looked at the code and it is 2^300. I suppose its too soon for windows x64 binaries.

20090404, 14:11  #5 
"Ben"
Feb 2007
D4C_{16} Posts 
Arrrgh, this too can fail when the inputs are 32 bits because (ab) can overflow past the point at which the high bit is set in t. Looks like you need to replace with < if (a >= b) < return a  b; < else < return a  b + p; Why is the CMOV code not running, I wonder? What system is this on? 
20090404, 14:22  #6  
Tribal Bullet
Oct 2004
3^{3}×131 Posts 
Quote:
Early in the QS days I could have sworn that gcc emitted CMOVs in 64bit code anyway, so I didn't bother. But it apparently is pretty selective about doing so, because it does not insert CMOVs in the code emitted for mp_mod{addsub}_1 a lot of the time. PS: Yes, you can generate NFS polynomials for inputs as small as 300 bits. Degree 5 is definitely suboptimal at this size, and QS on 90 digit inputs takes less than 90 minutes on a fast CPU, so you'll definitely find a crossover point somewhere in that range. If we had good degree4 polynomials (i.e. a lot better than what GGNFS polyselect finds), then perhaps with a 64bit lattice siever you can push the crossover point lower. Last fiddled with by jasonp on 20090404 at 14:41 

20090404, 15:56  #7 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9,391 Posts 
It was a Phenom940 with openSUSE. Of course, as soon as I switched to the 1.39 defs in the hybrid 1.40 and now in 1.41, the sqrt worked as well as always. It's ok, it's minimal.

20090404, 16:34  #8 
"Nancy"
Aug 2002
Alexandria
2,467 Posts 
I, too, noticed that gcc often doesn't put a CMOV where I would have. But often, when I added some inline assembly to force a CMOV, I found it not to be any faster... I think short forward jumps are probably not such a great performance problem, the CPU might just cancel the instructions that got jumped over. But these jumps probably still get their entry in the branch predictor so it might not be wise to have them all over the code.
Code that should be correct and may lure gcc into issuing a CMOV might be Code:
unsigned long submod (const unsigned long a, const unsigned long b, const unsigned long m) { unsigned long t = 0, r; if ((r = a  b) > a) t = m; r += t; return r; } Code:
submod: .LFB2: xorl %eax, %eax # tmp65 subq %rsi, %rdi # b, r cmovb %rdx, %rax # m,, tmp65 addq %rdi, %rax # r, tmp64 ret Alex Last fiddled with by akruppa on 20090404 at 16:40 
20090404, 19:07  #9 
Oct 2006
vomit_frame_pointer
2^{3}·3^{2}·5 Posts 
Polynomial search selectivity
(This is really an observation about v. 1.40, but I'll post here with the assumption that this feature is the same for 1.41. I started these 4.5 days ago, when 1.40 was the latest and greatest. )
I am 110 hours into two polynomial searches, on for a C148, and the other for a C154: Code:
9661238722345689010630695805381314354326302931463660867557848239569163056314130303253566711209106136015278104495960724308980934671618212504467824067414937 4999528981920039977105928887012630536149642830387837444118606677005916883919115505757408444772548420175203885179819335136297859682704476680388304121 Code:
save 1.849295e14 7.706762 4463134.747651 6.003133e12 save 1.978885e14 7.667151 4754630.164191 6.222547e12 save 1.853135e14 7.483809 4591571.198680 5.985121e12 save 1.902571e14 7.444414 4827192.155067 5.996877e12 save 1.842315e14 7.354144 4071249.338413 5.909207e12 save 1.915950e14 7.845139 4231063.399774 6.094013e12 (I think of alpha < 7 as a luxury, let alone 7.7 and 7.8. Most of my gnfs polynomials have had alpha values in the 6s.) As for the C154, it has around a week remaining, but with 4.5 days down, no candidates as yet. After the time limit is up, I can always continue manually from where the selector timed out  2.5 weeks searching for a C154 does not seem excessive. Still, things look a little lean. For a C158 I did a few weeks ago, I spent 3 coreweeks trying to improve on the great polynomial that popped up after two days. OTOH, if it always finds me a candidate with alpha below 7.5, I'll never complain. Last fiddled with by FactorEyes on 20090404 at 19:22 
20090404, 19:23  #10  
Jun 2003
Ottawa, Canada
494_{16} Posts 
Quote:
I will hopefully have time to produce some Windows 64bit binaries tonight after the kids go to bed. Jeff. 

20090404, 19:38  #11 
Sep 2004
13·41 Posts 
Yes, it will meet my needs, assumming qs is faster at 2^300, which is quite likely for now. Thanks for your work!

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Msieve 1.53 feedback  xilman  Msieve  149  20181112 06:37 
Msieve 1.50 feedback  firejuggler  Msieve  99  20130217 11:53 
Msieve v1.48 feedback  Jeff Gilchrist  Msieve  48  20110610 18:18 
Msieve 1.43 feedback  Jeff Gilchrist  Msieve  47  20091124 15:53 
Msieve 1.42 feedback  Andi47  Msieve  167  20091018 19:37 