20121206, 05:35  #34 
Jul 2003
So Cal
2253_{10} Posts 

20121211, 22:07  #35 
Jul 2003
So Cal
8CD_{16} Posts 
From my 1.3 million stage 1 hits, so far I've gotten a
# norm 4.371817e20 alpha 11.383344 e 2.347e19 rroots 4 The run continues... 
20121212, 01:49  #36 
Tribal Bullet
Oct 2004
3×1,181 Posts 
I sent a batch of hits computed with a cutoff of 5e33 instead of the previous 1e33, and apparently the polynomials generated with the looser cutoff are similar in quality. So if you use 5e33 for the stage1_norm you'll generate hits about 5x faster.

20121212, 09:17  #37 
"Carlos Pinho"
Oct 2011
Milton Keynes, UK
5×7×11×13 Posts 
So it's better to update first post.
Last fiddled with by jasonp on 20121212 at 12:32 Reason: yup, done 
20121213, 23:52  #38  
May 2011
10111_{2} Posts 
Quote:
Code:
Y1: 48957407582916194761589 Y0: 3626941552197564826492128852700460060642852 c6: 181000001476800 c5: 21292410351587764080336 c4: 1036456362256909021188219944324 c3: 28697722660097589508721192118263624637 c2: 174314770228113076791419006080421369720970639 c1: 2408464141902741608017790242140644715688145388490381 c0: 26101732745933806144485280988037796254029367990700826499285 skew: 20504576.000 # lognorm: 83.45, alpha: 12.19 (proj: 3.18), E: 71.26, nr: 2 # MurphyE(Bf=10000000,Bg=5000000,area=1.00e+16)=3.39e19 Last fiddled with by bai on 20121213 at 23:53 

20121214, 01:30  #39 
Tribal Bullet
Oct 2004
110111010111_{2} Posts 
Msieve computes an Evalue of 2.339e19 when using the skew computed by CADO. Would it be worthwhile to find out what causes such big differences?

20121214, 09:31  #40 
Nov 2010
62_{8} Posts 
Ok, here are about 1.8M hits for the new bound 5e33. It seems the tighter bound was better: with 1e33 as a bound on stage 1 after size optimizations I saw norms of about Xe32 whereas the new bound gives only Xe33 and worse. The best e for this pack was about 2.2e19.
Bai, I used E.sage from the public CADO repository and got almost the same Murphy e values as msieve shows. Do you compute it somehow different now? Last fiddled with by poily on 20121214 at 09:35 
20121214, 16:13  #41 
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 89<O<88
3×29×83 Posts 
As a bystander who has no knowledge of either how to go about such finding out or how much work it might be, I would be very interested in the results. (poily's post directly above this makes it all the more interesting!)

20121214, 16:26  #42 
Sep 2009
3D2_{16} Posts 
For the purposes of generating several hits with CPUs (as I can't currently use my GPU...) more quickly, I resurrected poily's MPI polsel patch, from http://www.mersenneforum.org/showpos...39&postcount=9 .
Mainline msieve changed somewhat since then (e.g. separation of the size optimization and the root sieve), so I started by upgrading and expanding the additions to the code; I also changed whitespace to follow the coding convention of the surrounding code more closely That allowed the computer to produce a number of hits with: $ mpirun n 6 msieve np1 "stage1_norm=2e33 1100000000000,1100010000000" v I think it would be great to see the MPI polsel patch integrated to mainline msieve. This way, every user of multithreaded polsel (even on a single computer) would benefit without having to apply (and upgrade) an out of tree patch However, AFAICS, the patch requires improvements before this can happen. Indeed, I noticed that when a child process has finished working ("polynomial selection complete"), it sticks its core to 100% usage. One of the processes found no suitable leading coefficient in its range and gave up on polsel immediately; after ~2h47 of CPU time wasted by that one, soon after another process had exhausted its range as well, I tried to kill one of the inactive processes... which killed all of its siblings, as I should have expected... 293 stage 1 hits generated in ~10h40 CPU time on Xeon E31230 @ 3.2 GHz. I have zero MPI experience, and therefore, no clue how to make finished jobs not waste significant CPU power 
20121214, 18:01  #43 
Tribal Bullet
Oct 2004
3·1,181 Posts 
The patch makes all the MPI processes wait at a barrier when poly selection is finishing, and my experience with OpenMPI is that this is a computationally expensive operation. I suspect that's what is burning up 100% CPU.
Unfortunately there's no real way around that, if you wanted processes to stop waiting on each other then you wouldn't be using barrier synchronization; put another way, MPI is a poor substitute for a distributed clientserver architecture :) 
20121214, 20:22  #44 
"Vincent"
Apr 2010
Over the rainbow
2·3·457 Posts 
ran a 15 min 'search' on a 560, got 227 hit, best poly
Code:
Fri Dec 14 21:18:19 2012 Msieve v. 1.51 (SVN 766) Fri Dec 14 21:18:19 2012 random seeds: ccf343ec 7dcd68de Fri Dec 14 21:18:19 2012 factoring 412023436986659543855531365332575948179811699844327982845455626433876445565248426198098870423161841879261420247188869492560931776375033421130982397485150944909106910269861031862704114880866970564902903653658867433731720813104105190864254793282601391257624033946373269391 (270 digits) Fri Dec 14 21:18:21 2012 no P1/P+1/ECM available, skipping Fri Dec 14 21:18:21 2012 commencing number field sieve (270digit input) Fri Dec 14 21:18:21 2012 commencing number field sieve polynomial selection Fri Dec 14 21:18:21 2012 polynomial degree: 6 Fri Dec 14 21:18:21 2012 max stage 1 norm: 1.08e+035 Fri Dec 14 21:18:21 2012 max stage 2 norm: 1.05e+035 Fri Dec 14 21:18:21 2012 min Evalue: 0.00e+000 Fri Dec 14 21:18:21 2012 poly select deadline: 1079999 Fri Dec 14 21:20:02 2012 polynomial selection complete Fri Dec 14 21:20:02 2012 R0: 3334009071282816277832905784211277620964254 Fri Dec 14 21:20:02 2012 R1: 100281358245707420758237 Fri Dec 14 21:20:02 2012 A0: 372828901627475347894334652824133151170797461276260673 Fri Dec 14 21:20:02 2012 A1: 77826863799406908305447316219479205604506482315 Fri Dec 14 21:20:02 2012 A2: 8440449792077225990613216882014698768493181 Fri Dec 14 21:20:02 2012 A3: 434343399475320970345769932599595433 Fri Dec 14 21:20:02 2012 A4: 27102576369602076901509411656588 Fri Dec 14 21:20:02 2012 A5: 139702468047107462100798 Fri Dec 14 21:20:02 2012 A6: 300000002082000 Fri Dec 14 21:20:02 2012 skew 1498026.43, size 1.811e020, alpha 8.436, combined = 1.092e019 rroots = 4 and the msieve.dat.m file to be run in cado Last fiddled with by firejuggler on 20121214 at 21:09 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Volunteers needed  axn  GPU Computing  28  20120528 12:05 
call for volunteers: RSA768 polynomial selection  jasonp  Operation Kibibit  200  20111105 21:31 
Call for help  Wacky  NFSNET Discussion  13  20050714 00:25 
Volunteers needed!  Xyzzy  Hardware  23  20030418 23:27 
We need two volunteers...  Xyzzy  PrimeNet  8  20030227 02:26 