20120113, 19:32  #276 
Jun 2003
Ottawa, Canada
3×17×23 Posts 

20120114, 16:27  #277  
Jun 2005
lehigh.edu
1024_{10} Posts 
Quote:
I'm easily distracted, or anything. Fortunately, it's a weekend, so many of the [older, nonavx] i7 sites are closed (to the public), so available for benchmarking. I'm trying both i2 binaries; except that I switched ATH's so as not to use asmredc; mostly the numbers below c234 are running on the 8core/AMD cluster, and the i7's at/above c234. (If I have that division correctly stated, asm vs nonasm.) Bruce 

20120115, 14:14  #278  
Jun 2005
lehigh.edu
2^{10} Posts 
Quote:
Code:
outcor2b3m701ai7_noavx.2:Step 1 took 6790879ms outcor2b3m701ai7_noavx.2:Step 2 took 2451868ms outcor2b3m701ai2.2:Step 1 took 7025255ms outcor2b3m701ai2.2:Step 2 took 2310484ms outcor2b3m701bwin.2:Step 1 took 5933108ms outcor2b3m701bwin.2:Step 2 took 2069353ms a clear win for Yamato's binary. Of course, with 8 curves running at the same time on these older i7's, there's some prospect of interference, but the win64 timings are consistent. A recent 3am status shows 168 of these corei7's, so 8*168 = 1344 curves at once. Regards, Bruce  Here's a 2nd opinion, on 3L/M, 1599, C226/C212: Code:
outcor2b3L1599ai2.1:Step 1 took 5394046ms outcor2b3L1599ai2.1:Step 2 took 1777257ms outcor2b3L1599bwin.1:Step 1 took 5164225ms outcor2b3L1599bwin.1:Step 2 took 1975004ms outcor2b3L1599a_noavx.1:Step 1 took 5047677ms outcor2b3L1599a_noavx.1:Step 2 took 2000307ms  outcor2b3M1599ewin.1:Step 1 took 4423158ms outcor2b3M1599ewin.1:Step 2 took 1564955ms outcor2b3M1599fi2.1:Step 1 took 4755784ms outcor2b3M1599fi2.1:Step 2 took 1721050ms outcor2b3M1599a_noavx.1:Step 1 took 4411209ms outcor2b3M1599a_noavx.1:Step 2 took 1688539ms running on the 8core/linux/AMD's, aside from these numbers reserved B+D snfs. Last fiddled with by bdodson on 20120115 at 14:31 Reason: 2nd opinion 

20120115, 16:46  #279  
Einyen
Dec 2003
Denmark
17·197 Posts 
Quote:
I tested my old 6.3 and 6.3.1 binaries versus the new 6.4 and the new version is 26% slower above 200 digits in stage1 but about the same speed for stage2, though I'm only testing for the lower B1/B2 values. core264bittests.html corei764bittests.html I briefly tested 6.3.1 compiled with MPIR 2.5.0 and 6.4 compiled with MPIR 2.4.0 and 6.3.1 matches the old 6.3.1 faster times while 6.4 matches the other 6.4 times, so it's gmpecm that is a bit slower not mpir. Last fiddled with by ATH on 20120115 at 16:49 

20120115, 19:12  #280  
Sep 2010
Scandinavia
615_{10} Posts 
Quote:
Btw; Does anyone know why this happens? 

20120116, 04:18  #281  
"Frank <^>"
Dec 2004
CDP Janesville
4112_{8} Posts 
Quote:
Last fiddled with by schickel on 20120116 at 04:20 Reason: Changing reason... 

20120117, 20:22  #283  
"Frank <^>"
Dec 2004
CDP Janesville
100001001010_{2} Posts 
Quote:
I would venture to guess that some internal limit is still being hit (or the limit check is left over.) What B1 bounds are you trying to use? 

20120117, 20:36  #284  
Sep 2010
Scandinavia
267_{16} Posts 
Quote:
B1=30 works, but if I add 'B2scale 4' it fails. B1=100 fails, but if I add 'B2scale 0.5' it works. It prints the stage1 time before it fails. Higher bounds work for smaller inputs. Last fiddled with by lorgix on 20120117 at 20:37 

20120122, 15:09  #285  
Jun 2005
lehigh.edu
2^{10} Posts 
Quote:
of the numbers; here's C271, B1=400M, all with B2=15892277350966. Code:
3m671dwin.1:Step 1 took 7939328ms 3m671dwin.1:Step 2 took 3640892ms 3m671e_63.1:Step 1 took 7673189ms 3m671e_63.1:Step 2 took 3556761ms 3m671fi2.1:Step 1 took 6386322ms 3m671fi2.1:Step 2 took 2944457ms reports using gmp, win is Yamato's (which won in c261), and the i2 is the core2 binary with MPIR, but without redc. Actually, win reports using redc, so maybe this is up in the range where without asmredc is better. Anyway, I'll be using ATH's i2 binary from here, up. I still have the largest range to check, c290c3xx, using B1=600M, a 63binary vs the winner here. Bruce 

20120124, 02:41  #286 
Einyen
Dec 2003
Denmark
17·197 Posts 
Lately I have been wondering if it would be feasible to make a "compilingkit" for GMPECM, so people could compile their own version.
Since Msys and Mingw64 do not need to be installed they could be just compressed along with some batch files for compiling mpir and gmpecm. If it works it would be just a matter of starting msys and running a few batch files to compile it. Any interest in this idea? Anyone want to test if it works? It will involve downloading a 77 Mb 7zipfile. Edit: Forgot to mention this is for 64 bit Windows only. I could make one for 32 bit later if needed. Last fiddled with by ATH on 20120124 at 02:50 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Project Links  masser  Sierpinski/Riesel Base 5  25  20111126 09:21 
Links to Precompiled Msieve versions  wblipp  Msieve  0  20110717 20:59 
Links  davieddy  Information & Answers  9  20101008 14:27 
Links question  ET_  PrimeNet  0  20080126 09:35 
Links.  Xyzzy  Forum Feedback  2  20070318 02:17 