20090108, 20:54  #1 
Jan 2009
1/n
3·7 Posts 
Question on going deep and using cores
Hey All,
I've checked the forums and help, but I can't seem to find an answer, (and could very well be I don't know the "right" question to ask) so if anyone could point me in the riht direction  much appreciated. Questions: 1. To go "deep" on a particular exponent with no factor found lets say 100000001 (just an example  but a 9 digit exponent) when one says "67 bit depth" is that when you set p95 under manual P1 with the parameters: a. 67 x 2 (1000000001) with B1=100000 and B2=0? and is that equivelent to b. 1 x 2 (100000001) with B1=100000 and B2=0? So the I guess is a.=b.? and if not which one should I do to prep an exponent as much as possible before the LL test? 2. I have a computer with 4 cores. is there any way to tweak p95 do use all 4 cores on the processing of 1 exponent? I checked the undoc.txt and see you can manually edit this but I don't want to futz something up. As it stands right now doing a P1 on an exponent only uses 25% CPU capability. Any light anyone can shed on the above would be much appreciated! thanks! 
20090109, 00:55  #2 
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
2·3·1,597 Posts 
Bit depth and P1 are oranges and limes.
Bit depth refers to how far an exponent has been trial factored. P1 has bounds, B1 & B2. Normally you want to factor an exponent to a predetermined bit depth (based up the size of the exponent) or until a factor is found, then do P1. (George has changed this a little, factor to goal_bit2, P1, continue to factor to goal_bit.) If you are looking at exponents in the 332,000,000 range, the factor goal_bit level is 77. If you are in a rush to get a particular exponent done (and are willing to possibly waste some effort), you can have multiple cores work on the exponent. Here is how I would structure a worktodo.txt file to get 332,000,0001 (a hypothetical example), from a preexisting bit depth of 61, up to 74, on a 2 core machine. Code:
[worker #1] factor=332000000,61,62 factor=332000000,63,64 factor=332000000,65,66 factor=332000000,67,68 factor=332000000,69,70 factor=332000000,71,72 factor=332000000,73,74 [worker #2] factor=332000000,62,63 factor=332000000,64,65 factor=332000000,66,67 factor=332000000,68,69 factor=332000000,70,71 factor=332000000,72,73 
20090109, 02:24  #3  
1976 Toyota Corona years forever!
"Wayne"
Nov 2006
Saskatchewan, Canada
2·3·773 Posts 
Quote:
For example on my Q9550 4core each core can complete a LL test on an exponent in the 47M range in about 35 days. If I configure it to use 2 cores for an exponent it will take about 20 days. Going to 3 or 4 gets even worse. However on a recent test on my 2core E6600 I found that a 18M double check ran almost exactly twice as fast with two cores. Last fiddled with by petrw1 on 20090109 at 02:25 

20090109, 04:12  #4 
Jan 2009
1/n
25_{8} Posts 
Thanks Uncwilly! The syntax for the worktodo files helps alot. (There isn't a menu for "bit depth" in the advanced tab, so the whole "bit depth" thing everyone talks about and I suppose everyone assumes you know the sytax from the "old days" or something.
Petrw1  Yeah on my particular machine if I do 3 or more cores there is this weird jump in the 4096k range, then goes down by double, and I've seen the same thing with using 3+ cores for LL test. Definately agree  I seem to get best results with running 2 x cores MP Last fiddled with by MercPrime on 20090109 at 04:13 
20090109, 07:42  #5 
Nov 2008
San Luis Obispo CA
2^{7} Posts 
Most of the Core 2 Quad chips are actually two dualcore CPUs on one die. Thus, each dualcore CPU has an independent cache. Running three or four cores on one exponent causes data to be needed that is in the other (nonlocal) cache.

20090109, 10:03  #6 
Sep 2002
Oeiras, Portugal
3·487 Posts 

20090109, 15:29  #7  
1976 Toyota Corona years forever!
"Wayne"
Nov 2006
Saskatchewan, Canada
4638_{10} Posts 
Quote:
With only one core doing a LL at 47.7M it was about 0.058 per iteration. With 3 cores doing LL at that level and 1 core doing P1 I was averaging about 0.066 seconds while P1 was in Phase 1 and about 0.068 when P1 was in phase 2. Related to that, my P1 core is working in the 50M range using 1024M RAM. It is taking about 21 hours for Phase 1 and about 36 hours for Phase 2 for a total of 57 hours. The Test... Status menu keeps telling me they entire P1 should finish in 50 hours. If these numbers are out of line then I need to check into it. 

20090109, 23:00  #8  
"Oliver"
Mar 2005
Germany
11·101 Posts 
Quote:
Code:
[worker #1] factor=332000000,61,73 [worker #2] factor=332000000,73,74 

20090110, 00:47  #9 
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
2×3×1,597 Posts 
Depends on how much you want it to get done in the absolutely shortest time possible, or in about as fast as possible and avoid some wasted effort. If one was running 3 cores, sure do the high bit on one and interleave the others (even a smarter interleave).

20090110, 11:07  #10  
Sep 2006
Brussels, Belgium
2×5×167 Posts 
Quote:
Even if doing the lower order on one one core and the highest bit on another you could find a factor early on in the highest bit, meaning that : first of all you are not shure you have found the smallest factor* but also that you have to rearange all your work to stop the now unnecessary testing. As for the speedup it will be relative : each level will take double the time of the preceding one, this means that you use at most twice the time of the longest one when working sequentially. But the minimum time (when no factor is found) is the time neede by the highest bit level. That means that you have to put all the other bit levels on the other core. Bringing in more cores will not help to shorten the time. (In your example of interleaving Worker #1 would need twice the time Worker #2 needs to complete the assignment.) All in all the method proposed by The Judger makes most sense if working out of sequence. I would stick to sequential trial factoring , use the other cores to work on other exponents ;) Jacob * Prime95 will stop at the first factor found, so the factor reported is not always the smallest, but this is whithin one bit level. Last fiddled with by S485122 on 20090110 at 11:22 Reason: the interleaving schemes 

20090110, 15:28  #11 
"Richard B. Woods"
Aug 2002
Wisconsin USA
2^{2}×3×641 Posts 
Because the GIMPS database currently has no way to record that TF on some exponent skipped some bit levels (e.g., 063, 6667, without any TF from 2^{63} to 2^{66}, will be recorded simply as having been TFed to 67), I urge all TF to be strictly sequential. (But see OTOH below.)
Not even Code:
[worker #1] factor=332000000,61,73 [worker #2] factor=332000000,73,74 Of course, it would be better to institute a way to accurately record discontinuous, partial and fractional TFrange completions. On The Other Hand: We currently know for sure that the GIMPS recording of simply the highest TF bitlevel is misleading and incomplete, and thus are not leaving as solid a legacy of comprehensive sweep there as we are in LL testing. This argues against my previous admonition of strictlysequential TF, since even those cases must and will be viewed as suspect in the future, as long as our current recording of results is flawed as it is.    Just to quantify the inefficiency of Code:
[worker #1] factor=332000000,61,73 [worker #2] factor=332000000,73,74 Worker #1 has a factorfinding chance of 1/62 + 1/63 + ... + 1/73. Worker #2's chance is only 1/74 even though it requires slightly (~ 0.024%) more time than worker #1's assignment. It's far more likely that worker #1 will find a factor before worker #2 does (or finishes) than that worker #2 will find a factor before worker #1 does (or finishes). Worker #2's effort is more likely to be wasted than worker #1's. Last fiddled with by cheesehead on 20090110 at 16:09 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
News from subproject Deep Sieving  Batalov  Operazione Doppi Mersennes  58  20210205 10:44 
Deep Sieving MM49 in parallel  ET_  Operazione Doppi Mersennes  22  20160728 11:23 
What does Glib Deepak have to do with deep doodoo?  cheesehead  Science & Technology  47  20141214 13:45 
Deep Hash  diep  Math  5  20121005 17:44 
NASA's Deep Impact...  ixfd64  Lounge  5  20050706 13:46 