GAPS ≥ 1346
 

All the gaps ≥1346 found up to now. 12 gaps
[CODE]

Thomas11 1380 4161256227746743067 (new CFC)
antonio 1372 4219088970046367161 (new CFC)
antonio 1440 4253027105513399527 (new CFC)
Thomas11 [COLOR="Red"]1352[/COLOR] 4459397360427487997
robert44444uk [COLOR="red"]1430[/COLOR] 4606937813294064947

Thomas11 1368 4105079953458040849
antonio 1362 4223823832453807411
danaj 1386 4322110169397191503
Thomas11 1362 4457902027708963871
pinhodecarlos 1350 4480897278955294741
danaj 1374 4709939493140870509
danaj 1454 4883011923347099963


to be rediscovered
[COLOR="red"]1346[/COLOR] 4646044042396639877

Exhaustive search [B]4000-4285[/B]
The gaps in red are set to become new CFC when the exhaustive search reaches
their level[/CODE]

[QUOTE=danaj;462220]4883011923347099963 +1454

Does not beat the CFC 3219107182492871783 found by TOeS et al.[/QUOTE]

4484-4488 done.

[QUOTE=R. Gerbicz;462190]It is better to test the default 1e15 range, you can stop the program at the first sieve rate print. (you have to wait for it roughly 30 minutes on a fast core-i7).
For me using sb=24;bs=18 gives a speedup of 1%. (note the reduced sb value, but sb=25 has giving close rate).

Investigating the mentioned ideas.[/QUOTE]I noticed that there was less of a speed-up on my laptop when I used 8 threads. I think it may have something to do with using the hyperthreaded cores (possibly as a result of them sharing the same L1 & L2 cache).

I changed the implementation of prec_prime and next_prime to a simple finite state machine to gain a very slight speed advantage with the current 30-wheel (on my i5). It has the advantage that we could change to a 210-wheel with only a small space penalty, see the attached code snippet, although it would appear that other parts of the code would need to be changed to achieve this.

4285-4290e15 & 4293-4296e15 completed[CODE]4285-4286e15 96 kgaps, largest 1200 @ 4285926639789943867
4286-4287e15 106 kgaps, largest 1110 @ 4286405708090045699 & 4286826307449112463
4287-4288e15 106 kgaps, largest 1198 @ 4287652227904614601
4288-4289e15 123 kgaps, largest 1176 @ 4288453396401341977
4289-4290e15 108 kgaps, largest 1254 @ 4289835634738455163

4293-4294e15 100 kgaps, largest 1194 @ 4293752836757256683
4294-4295e15 104 kgaps, largest 1144 @ 4294660188655266439
4295-4296e15 111 kgaps, largest 1166 @ 4295513389087089131
[/CODE]

4580-4590e15 and 4812-4820e15 completed:
[CODE]
4580-4581e15 119 kgaps, largest 1236 @ 4580004190163725703
4581-4582e15 107 kgaps, largest 1194 @ 4581127351923798479
4582-4583e15 111 kgaps, largest 1218 @ 4582794353103422179
4583-4584e15 130 kgaps, largest 1214 @ 4583263715681536913
4584-4585e15 102 kgaps, largest 1170 @ 4584779156263856831
4585-4586e15 99 kgaps, largest 1152 @ 4585841611703209639
4586-4587e15 112 kgaps, largest 1246 @ 4586589820950683827
4587-4588e15 102 kgaps, largest 1150 @ 4587409949653703113 & 4587822569709311299
4588-4589e15 97 kgaps, largest 1200 @ 4588278529210387667
4589-4590e15 122 kgaps, largest 1128 @ 4589624940904024771

4812-4813e15 94 kgaps, largest 1224 @ 4812155922556440923
4813-4814e15 95 kgaps, largest 1202 @ 4813465327385798537
4814-4815e15 89 kgaps, largest 1212 @ 4814150594247860687
4815-4816e15 95 kgaps, largest 1190 @ 4815828621985778357
4816-4817e15 81 kgaps, largest 1216 @ 4816276856995074853
4817-4818e15 80 kgaps, largest 1166 @ 4817124149233745543
4818-4819e15 101 kgaps, largest 1166 @ 4818681234243298013
4819-4820e15 104 kgaps, largest 1220 @ 4819863593651777393
[/CODE]

I'd like to take 4560-4575e15 as well - closing the [I]gap[/I].

[QUOTE=Antonio;462233]I changed the implementation of prec_prime and next_prime to a simple finite state machine to gain a very slight speed advantage with the current 30-wheel (on my i5). It has the advantage that we could change to a 210-wheel with only a small space penalty, see the attached code snippet, although it would appear that other parts of the code would need to be changed to achieve this.[/QUOTE]
Just to correct the 210 wheel arrays, these should be:[CODE]//static const int wheel[48]={2,10,2,4,2,4,6,2,6,4,2,4,6,6,2,6,4,2,6,4,6,8,4,2,4,2,4,8,6,4,6,2,4,6,2,6,6,4,2,4,6,2,6,4,2,4,2,10};
//static const int spoke[48]={1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,0};
[/CODE]I really should check before I post :redface:

[QUOTE=Antonio;462253]Just to correct the 210 wheel arrays, these should be:[CODE]//static const int wheel[48]={2,10,2,4,2,4,6,2,6,4,2,4,6,6,2,6,4,2,6,4,6,8,4,2,4,2,4,8,6,4,6,2,4,6,2,6,6,4,2,4,6,2,6,4,2,4,2,10};
//static const int spoke[48]={1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,0};
[/CODE]I really should check before I post :redface:[/QUOTE]

I was also considering the extension of the current 30 wheel (=2*3*5) to a 210 wheel (=2*3*5*7). But the then necessary (fast) [I]i%48[/I] operation kept me puzzling. While for [I]i%8[/I] one could (and Robert G. actually did) use the equivalent (and faster) [I]i&7[/I], there is no such replacement for [I]i%48[/I] - until you came with your [I]spoke[/I] array. :smile:

The second parameter ([I]mod[/I]) of function [B]lin_solve[/B] doesn't change during runtime. It's equal to [I]mingap2[/I], which itself would be equal to 1050 for our current optimal settings (gap=1250, delta=155).

Thus, it might be worth to replace it by a constant. This would save us 2 time consuming DIV operations, since the compiler optimization would replace the divisions by multiplications by it's reciprocal.

[CODE]ui32 lin_solve(ui64 f,ui32 mod,ui32 res,ui32 p){
// Solve (x+f)*mod+res==0 modulo p
// assume that gcd(p,mod)=1
// x==-res/mod-f modulo p
ui32 r=p%[COLOR="Red"]mod[/COLOR]; [COLOR="Red"]// mod --> 1050[/COLOR]
ui64 k=(ui64)p*inv_mod[r];
k=(k-1)/[COLOR="Red"]mod[/COLOR]; [COLOR="Red"]// mod --> 1050[/COLOR]
r=((ui64)res*k)%p;
f%=p;
if(r>=f)r-=f;
else r+=p-f;
return r;
}
[/CODE]

Most of the [B]4000-4500[/B] e15 Range is completed. The only remaining e15 ranges are 4296, 4297, 4298, 4299 and 4487-4900
Once this ranges are finalized the exhaustive search will reach 4513 and 2 more C?C will become CFC.

[B]From 4500-5000[/B]
Range 4500-4600 50% completed
Range 4700-4800 100% completed
Other Ranges are between 10% and 48% completed.


The total advance 4000-5000 is [B]726[/B] ranges completed. 374 to go.

[CODE]4680 4681 mart_r done no 1264 4680580355418884419
4681 4682 mart_r done no 1202 4681200005723545211
4682 4683 mart_r done no 1198 4682049089807621173
4683 4684 mart_r done no 1122 4683161300012483851
4684 4685 mart_r done no 1182 4684493096794941877
4685 4686 mart_r done no 1234 4685557731895999867
4686 4687 mart_r done no 1192 4686955484546486971
4687 4688 mart_r done no 1144 4687224219458112313
4688 4689 mart_r done no 1210 4688112528729748537
4689 4690 mart_r done no 1242 4689521661297857387
[/CODE]

Did anyone else notice the two new entries from Leif Leonhardy, at g=1408/1434?